static_cast<int>() vs short

[Dr. Prof]

Na wenn du nur was in die streams ausgeben willst, dann nimm char und caste.
Die formatierte ausgabe ist so zeitaufwändig, da fällt der cast nicht ins gewicht.

Das soll jetzt nicht heißen, dass du die nicht nehmen sollst, sondern dass du durch den cast nicht wirklich etwas gewinnst.

[Artchi]

Hier gehen ja manche echt ab! Bei Softwareentwicklung sollte man nicht nur an einzelne Bits denken oder an einen Taktzyklus. Der Sinn von Hochsprachen (auch C++) ist auch seinen Code lesbar und wartbar zu machen.

Wenn eine Variable nur max. 16bit Werte aufnehmen soll, dann bitte auch einen entsprechenden Datentyp wählen. Denn schliesslich soll der Nutzer einer Variable, Funktion usw. am Typ sehen können, was er erwarten kann. Wenn ich ein long sehe, dann heißt das für mich, das ich auch den long-Bereich ausnutzen kann. Und nicht zur Laufzeit feststellen muß, das meine übergebenen Werte beschnitten werden oder sowas.

[groovemaster]

CStoll schrieb:

Des Rätsels Lösung ist ganz einfach - "char" (und seine Brüder) ist zwar ein einfacher Ganzzahltyp, mit dem auch ganz normal gerechnet werden kann, hat jedoch immer noch die Bedeutung "Zeichen" im Hintergrund - und deshalb sind die Stream-Operatoren für char so überladen, daß sie die ASCII-Darstellung des übergebenen Wertes anzeigen

Das ist aber ein Fehler in den Streams der STL, imo. Nur char bedeutet Zeichen, signed char und unsigned char sind Ganzzahltypen mit Bytegrösse und sollten von cout auch entsprechend ausgegeben werden.

There are four signed integer types: “signed char”, “short int”, “int”, and “long int.”
[...]
For each of the signed integer types, there exists a corresponding (but different) unsigned integer type: “unsigned char”, “unsigned short int”, “unsigned int”, and “unsigned long int,”

Leider sieht der Standard eine andere Funktionsweise der überladenen Operatoren vor.