Bietet C++ eine Syntax fürs Casten bei zusammengesetzten Operatoren?

[Bashar]

Gugelmoser schrieb:

Bashar schrieb:

Also ich finde es gut, wenn vor so etwas gewarnt wird.

Schau dir mal die Regeln zu 'Usual arithmetic conversions' und 'integer promotions' im Standard an und überlege nochmal, ob das eine gute Idee ist.

Hmm, also ich habe den entsprechenden Teil 5/10 eben im Standard nachgelesen. Aber ich verstehe immer noch nicht, wieso diese Warnung unnütz sein soll. Immerhin könnte das Ergebnis der Addition ja zu groß für unsigned char sein und dann ist es doch schön, wenn der Compiler mich darauf hinweist. Erklärst du mir bitte, wieso es einen guten Grund hat, dass -Wall diese Art von Warnung nicht aktiviert ?

Weil diese impliziten Umwandlungen allgegenwärtig sind. Sämtliche Arithmetik passiert mindestens in int oder unsigned int, du müsstest also praktisch bei jeder Zuweisung mit einem short oder char-Datentyp auf der linken Seite casten, um die Warnung loszuwerden.

Und es ist ja nicht so, dass ein Cast einem da irgendwelche Sicherheit verheißt. Wenn man mit Warnungen überhäuft wird und dann alles mechanisch wegcastet, ist es am Ende unsicherer als vorher.

Wenn du das anders siehst, bitte schön, das ist ja in gewissen Grenzen auch Geschmackssache. Dann wirst du aber wahrscheinlich auch kein Problem damit haben, uc = static_cast<unsigned char>(uc + 55); zu schreiben

[Bashar]

cooky451 schrieb:

Du siehst also, dass das nichts mit dem Problem zu tun hat.

Es ist theoretisch schon ein Unterschied, ob eine Berechnung selbst einen Überlauf erzeugt, oder ob die Berechnung noch in einem größeren Datentyp erfolgt und erst bei der Runterkonvertierung ein Überlauf entsteht.

[cooky451]

Bashar schrieb:

Es ist theoretisch schon ein Unterschied, ob eine Berechnung selbst einen Überlauf erzeugt, oder ob die Berechnung noch in einem größeren Datentyp erfolgt und erst bei der Runterkonvertierung ein Überlauf entsteht.

Und der Unterschied ist?..

[Bashar]

cooky451 schrieb:

Und der Unterschied ist?..

Im ersteren Fall entsteht (zumindest bei signed-Typen) undefiniertes Verhalten. Das Überlaufverhalten beim Runterkonvertieren ist dagegen implementation-defined.

[camper]

cooky451 schrieb:

Bashar schrieb:

Es ist theoretisch schon ein Unterschied, ob eine Berechnung selbst einen Überlauf erzeugt, oder ob die Berechnung noch in einem größeren Datentyp erfolgt und erst bei der Runterkonvertierung ein Überlauf entsteht.

Und der Unterschied ist?..

Ersteres ist immer undefiniert, Letzteres nur, wenn Gleitkommazahlen im Spiel sind.

[cooky451]

Und zusammen bekommen wir:
- unsigned -> Immer defined
- signed -> undefined, defined beim Konvertieren.
- floating point -> Immer undefined.

[pumuckl]

Gut, dass es mit C++11 user defined Literals gibt

unsigned char myUchar = 10;
myUchar += 55uc; // uc: userdefined operator ""

Es sei dem geneigten Leser überlassen, den uc-Suffix für dezimale, oktale und hexadezimale Literale zu implementieren - mit Größencheck zur Compilezeit natürlich

[314159265358979]

Den muss man doch gar nicht für verschiedene Basen definieren.

[pumuckl]

314159265358979 schrieb:

Den muss man doch gar nicht für verschiedene Basen definieren.

Natürlich muss man nicht. Es sei denn man möchte ihn für verschiedene Basen zur Verfügung stellen. z.B. weil man eine Bibliothek schreibt und nicht irgendwelche halbgaren Dinge rausbringen will. Oder weils eine interessante Aufgabe ist

[314159265358979]

Anders gesagt: Man kann auch nicht, so weit ich weiß. Man kann zawr für jede Basis ein Suffix einführen, aber ein Suffix für mehrere Basen zu überladen ist meines Wissens nach nicht möglich.