Diskussion:C++-Programmierung/ Einführung in C++/ Rechnen mit unterschiedlichen Datentypen

Implizite Casts

Es wäre gut, wenn das Kapitel auf die Unterschiede zwischen (stets werterhaltender) "Promotion" und (nicht notwendigerweise werterhaltender) "arithmetic conversion" eingehen würde bei den impliziten Typumwandlungen. Auch sind die großen Tabellen, welcher Typ mit welchem Typ verknüpft welchen Zieltyp ergibt, ziemlich unübersichtlich. Ich würde das mit einer einfacheren Grafik veranschaulichen, die man einfach aus dem Regeln in Abschnitt 5, Absatz 9 im Standard erstellen kann. Dann würde man auch erkennen, dass etwa bei einem Aufeinandertreffen von unsigned und long das Ergebnis nicht zwangsläufig unsigned long ist, da der Ergebnisdatentyp plattformabhängig ist.
Soweit mein Senf erstmal dazu. --RokerHRO 20:43, 12. Jun. 2008 (CEST)

Ich hab den Fehler in der Tabelle korrigiert und mal die Regeln für die Typumwandlung ergänzt. Was die Unübersichtlichkeit der Tabellen angeht gebe ich dir vollkommen recht, das hat mich von Anfang an gestört. Leider bin ich im erstellen von Grafiken alles andere als gut, wenn du das übernehmen könntest währe ich dir Dankbar, ebenso für ein paar Worte zur werterhaltenden bzw. nicht werterhaltenden Typumwandlungen, entweder direkt im Kapitel oder als ein paar Stichpunkte hier, damit das schreiben nicht so lange dauert.

Viele Grüße --Prog 22:51, 12. Jun. 2008 (CEST)

Hast du den entsprechenden Abschnitt im Standard mal gelesen? Ich erlaube mir mal zu zitieren:

Many binary operators that expect operands of arithmetic or enumeration type cause conversions and yield result types in a similar way. The purpose is to yield a common type, which is also the type of the result. This pattern is called the usual arithmetic conversions, which are defined as follows:

• If either operand is of type long double, the other shall be converted to long double.
• Otherwise, if either operand is double, the other shall be converted to double.
• Otherwise, if either operand is float, the other shall be converted to float.
• Otherwise, the integral promotions (4.5) shall be performed on both operands.
• Then, if either operand is unsigned long, the other shall be converted to unsigned long.
• Otherwise, if one operand is a long int and the other unsigned int, then if a long int can represent all the values of an unsigned int, the unsigned int shall be converted to long int; otherwise both operands shall be converted to unsigned long int.
• Otherwise, if either operand is long, the other shall be converted to long.
• Otherwise, if either operand is unsigned, the other shall be converted to unsigned.

[Note: otherwise, the only remaining case is that both operands are int]

Was hältst du davon, wenn man das ins Deutsche übersetzt und dann einfach so übernimmt? --RokerHRO 14:10, 13. Jun. 2008 (CEST)

C-Funktion aus dem Text entfernen

Im Text wird die Funktion printf verwendet. Sie wird von diesem Buch nicht behandelt und sollte entsprechend entfernt werden. --Prog 20:47, 13. Mai 2009 (CEST)

Die Tabelle Ganzzahlen ist nicht schlüssig

Aktuell sagt die Tabelle Ganzzahlen aus, dass es in einem Fall auf die Reihenfolge des Zusammentreffens ankommt. Wenn long auf unsigned int trifft, soll es unsigned long werden. Wenn unsigned int auf long trifft, soll es "long oder unsigned long" werden. Vermutlich ist das unvollständig editiert, denn es wäre sonst eine entsprechende Erklärung nötig, warum die Reihenfolge des Zusammentreffens relevant ist.

In der Sache ist auch der Text "long oder unsigned long" unmittelbar erklärungsbedürftig. Der Leser erwartet eine Erläuterung welcher Mechanismus hinter dem "oder" steckt. Erst viel später erfolgt eine Übersetzung aus dem Englischen, die die Sache teilweise aufklärt. Dass der Text "falls ein long alle Werte eines unsigned int darstellen kann" auf die Version des Compilers und dessen Repräsentation der Zahlen Bezug nimmt, habe ich erst nach langen Irrwegen und Recherche herausgefunden. Ein Hinweis "Abhängig von der Version des Compilers" hätte geholfen.

Den englischen Text verstehe ich übrigens so, dass sich ohne Beteiligung von long-Typen grundsätzlich ein unsigned durchsetzt. Dementsprechend wäre die Tabelle Ganzzahlen großflächig falsch. --Arduino Kurt 15:38, 13. Aug. 2017 (CEST)

Allgemeine Verbesserungsvorschläge zum Text

Ich finde, es fehlen im Kapitel möglichst weit am Anfang einige allgemeine Erklärungen und manche Stellen sind unklar formuliert. Außerdem gibt es weitere Unstimmigkeiten:

1. Im vorigen Kapitel wird von vier Gruppen von Datentypen geschrieben: Wahrheitswerte, Zeichen, Ganzzahlen und Gleitkommazahlen. Macht es für die Sprache C++ einen Unterschied, ob man nur innerhalb einer Gruppe oder gruppenübergreifend umwandelt?
   • Falls Ja: darauf wird nicht genug eingegangen bzw. unterschieden. Zum Beispiel sind unter der Überschrift Implizite Typumwandlung ein paar Beispiele genannt, die aber jeweils für sich nur eine Gruppe betreffen, obwohl exakt diese Beispiele schon in den Tabellen weiter oben vorkommen (es sind ja keine Code-Beispiele). Danach unter Umformungsregeln ist nicht ersichtlich, ob auch gruppenübergreifende Umwandlungen gemeint sind, weil nicht spezifiziert wird, ob der Datentyp des 2. Operanden von der selben Gruppe sein muss oder nicht. Und weiter unten das letzte Beispiel zeigt auf einmal eine gruppenübergreifende Umwandlung. Und viel weiter unten gibt es eine ganze Überschrift Ganzzahlen und Gleitkommazahlen, unter der nur ein Satz steht aber kein Beispiel. Irgendwie muss das Ganze anders strukturiert werden.
   • Falls Nein: es scheint ja trotzdem eine logische Unterscheidung für den Leser im Text zu geben, die aber nicht deutlich genug gemacht wird (siehe unter Falls Ja).
2. Warum ist eine Typumwandlung notwendig und wer sorgt für jene (Compiler?), insbesondere beim impliziten Cast? Unter der Überschrift Implizite Typumwandlung steht: „Mit impliziter Typumwandlung hatten Sie bereits reichlich zu tun, denn es kann ausschließlich mit Zahlen gerechnet werden, die den gleichen Typ besitzen.“ Nunja, als Programmierer kann ich doch mit Zahlen unterschiedlichen Typs rechnen, zumindest kann ich sie im Quelltext ohne Fehlermeldung eingeben. Also wer kann ausschließlich mit Zahlen rechnen, die den gleichen Typ besitzen? Das muss klargestellt werden. Unter dem Beispiel weiter unten wird dann zwar beschrieben, dass vor der Berechnung umgewandelt wird aber das muss IMO schon früher und ausführlicher im Text geschehen und nicht auf ein bestimmtes Beispiel bezogen.
3. Zitat unter Umformungsregeln: „Viele binäre Operatoren, die arithmetische oder Aufzählungsoperanden erwarten, verursachen Umwandlungen und ergeben Ergebnistypen auf ähnliche Weise.“ Aus der Sicht eines Anfängers: Was sind binäre Operatoren? Was sind Aufzählungsoperanden? Es wird nicht erklärt.
4. Erster Satz Explizite Typumwandlung, C-Cast (Typ)Wert. Was ist eigentlich mit Typ(Wert)? Warum wird ersterer erwähnt und letzterer nicht?
5. Rechnen mit Zeichen: Ein Beispiel mit Schleifen und dann: „Für eine Erklärung des obigen Quellcodes lesen Sie bitte das Kapitel Schleifen.“ Ich finde, das geht gar nicht. Das sollte man ersetzen mit einem Quelltext, wo noch keine neuen Techniken drin vorkommen.
6. Nächster Satz: „Wenn Sie binäre Operatoren auf Zeichen anwenden, ist das Ergebnis (mindestens) vom Typ int.“ Aber auf jeden Fall ein Ganzzahltyp? Also ansonsten unsigned int, long, unsigned long, long long oder unsigned long long? Das sollte man auch ein bisschen spezifizieren.

--Pohli 21:17, 7. Aug. 2018 (CEST)

Das ist doch alles Kleinkram, der nichts am wesentlichen Problem ändert: Das Buch ist auf dem Stand C++98. Das interessiert niemanden. Der "zukünftige" Standard C++11 wird sporadisch erwähnt mit teils überholten Infos. C++14/17: gänzlich Fehlanzeige. Mit C++11/14/17 hat sich dermaßen viel getan, dass im Prinzip jeder Themenbereich neu aufgerollt werden muss. Eigentlich müsste top-down das ganz Buch neu durchdacht werden. Und angesichts des üblichen Tempos hier sollte gleich C++20 das Ziel sein. Buchfreund --92.202.139.100 23:00, 7. Aug. 2018 (CEST)