unsigned char uc = 10; 
uc += 55; // conversion to 'unsigned char' from 'int' may alter its value [-Wconversion]

Ich will diese Warnung beseitigen. Um Casten zu können muss ich auf uc=uc+55 ausweichen, oder?

Danke im Voraus.

EDIT: Irgendwie dachte ich es hätte 2 mal Gugelmonster geantwortet

uc += static_cast<unsigned char>(55);

http://www.cplusplus.com/doc/tutorial%20%20/typecasting/

Ich will diese Warnung beseitigen. Um Casten zu können muss ich auf uc=uc+55 ausweichen, oder?

Ja (mit Cast natürlich). Oder die Warnung abschalten. Es hat schon seinen Grund, warum sie mit -Wall nicht aktiviert wird.

Hilft uc += 55u; ?

Dann wird ja unsigned int draus. :p

Videonauth schrieb:

uc += static_cast<unsigned char>(55);

Der Cast bezieht sich auch nur auf die 55, nicht aber auf die Zuweisung an uc.

Bashar schrieb:

Gugelmoser schrieb:

Ich will diese Warnung beseitigen. Um Casten zu können muss ich auf uc=uc+55 ausweichen, oder?

Ja (mit Cast natürlich). Oder die Warnung abschalten. Es hat schon seinen Grund, warum sie mit -Wall nicht aktiviert wird.

Schon klar mit Cast. Mir ist nur keine Syntax bekannt, sodass sich der Cast auf das Ergebnis der Addition bezieht. Also ich finde es gut, wenn vor so etwas gewarnt wird.

x=static_cast<unsigned char>(x+55u)

aber das nicht:

x+=static_cast<unsigned char>(55u)

unsigned char + unsigned char wird zu int promoted

Seltsam, folgendes funktioniert:

x=static_cast<unsigned char>(x+55u)

Natürlich, der Cast bezieht sich ja auch auf das Ergebnis der Addition.

pyhax schrieb:

aber das nicht:

x+=static_cast<unsigned char>(55u)

unsigned char + unsigned char wird zu int promoted

Promotion findet trotzdem statt, auch wenn die Datentypen gleich sind.

Mir ist nur keine Syntax bekannt, sodass sich der Cast auf das Ergebnis der Addition bezieht.

Ich weiß, das ist doch deine Frage hier gewesen, und genau die habe ich beantwortet

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.

http://www.cplusplus.com/reference/clibrary/climits/

Gugelmoser schrieb:

Mir ist nur keine Syntax bekannt, sodass sich der Cast auf das Ergebnis der Addition bezieht.

Ich weiß, das ist doch deine Frage hier gewesen, und genau die habe ich beantwortet

Ups, ja natürlich. Sry

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 ?

Immerhin könnte das Ergebnis der Addition ja zu groß für unsigned char

int main()
{
  unsigned int c = 4294967295u;
  c += 1u;
}

Autsch. Mal angenommen sizeof(int) ist 32. Du siehst also, dass das nichts mit dem Problem zu tun hat.

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

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.

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?..

Und der Unterschied ist?..

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

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.

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

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