Größe von Standarddatentypen auf unterschiedlichen Systemen?

BugJoe schrieb:

Also legt der Compilerhersteller letztendlich die Größe der Datentypen fest? Nicht der Betriebsystemhersteller und nicht der Prozessorherteller?

So ist es!

BugJoe schrieb:

aber wie macht es jetzt beispielsweise der GCC? Legt der die Größe der Datentypen anhand der zugrunde liegenden Prozessorarchitektur fest?

Mußt du in die GCC-Doku schauen. Glaube nicht, das der GCC das pro Prozessor festlegt, sondern bestimmt jeder das selber bestimmen kann, wenn er einen GCC für eine Plattform baut.

BugJoe

Danke schön, jetzt bin ich wieder etwas schlauer

devkid

@BugJoe: Werf mal einen Blick in die stdint.h. Wenn du die Größen der Datentypen genau bestimmt haben willst, kannst du die typedefs darin verwenden, also z.B. int32_t für einen 32-bittigen signed int oder uint8_t für einen unsigned char.

Nexus

Hm, aber ist das so problematisch, dass z.B. ein int auch auf 32-Bit-Systemen nur 16 Bit breit sein kann? Wenn das so wäre und in der Praxis auch vorkäme, könnte das sicher zu etlichen nicht funktionierenden Programme führen. Und immer auf long bzw. short zurückzugreifen ist ja auch nicht das Wahre (abgesehen davon, dass man sich nicht mal dort sicher sein kann)...

BarnieGeroellheimer schrieb:

char <= bool <= short <= int <= long

Ist das beabsichtigt, dass ein Wahrheitswert eventuell mehr Werte annehmen kann als ein Zeichen repräsentierender Datentyp?

Christoph

Nexus schrieb:

BarnieGeroellheimer schrieb:

char <= bool <= short <= int <= long

Ist das beabsichtigt, dass ein Wahrheitswert eventuell mehr Werte annehmen kann als ein Zeichen repräsentierender Datentyp?

gcc auf Mac OS X auf der PowerPC-Architektur hat sizeof(bool) == 4, das kommt also auch bei nicht ganz so exotischen Systemen vor.

camper

Mit anderen Worten, bool hat in dieser Vergleichskette nichts verloren. Sicher ist nur, dass es einen integralen Typ gibt, der die gleiche Größe wie bool hat (analog: wchar_t).

Nexus

Ich nehme an, das rührt daher, dass es diese Typen in C noch nicht gab und sie sich in C++ deshalb an bereits existierenden Typen orientieren...

Und wie ist das jetzt mit dem int - muss man Angst haben, dass Programme wegen der 16-Bit-Breite nicht funktionieren, und besser auf long ausweichen?

Nexus schrieb:

Ich nehme an, das rührt daher, dass es diese Typen in C noch nicht gab und sie sich in C++ deshalb an bereits existierenden Typen orientieren...

Und wie ist das jetzt mit dem int - muss man Angst haben, dass Programme wegen der 16-Bit-Breite nicht funktionieren, und besser auf long ausweichen?

Nö, das bringt dir auch nichts, da ja long schliesslich auch 16 bit sein kann. Wie gesagt, benutzt <limits> ! Dafür ist der Header gedacht! Mit tempaltes lässt sich dann der Typ entscheiden.

Oder definiert euch ein typedef, da ihr je nach Plattform einsetzt:

typedef int int32;
typedef short int16;

Und benutze dann int32, und bei einer anderen Plattform brauchste blos das typedef an einer Stelle anpassen.

Nexus

Sehr schön. Kurz gesagt, kann man die eingebauten Typen wie char , short , int , long in den Mülleimer kippen, wenn man auf den Wertebereich achten will?

Kaum, oder? Ich denke, es ist durchaus legitim, sich in den meisten Fällen auf die Standardbreiten zu verlassen...

Also mal ehrlich. Der normale Menschenverstand sagt einem, das die meisten 32-Bit-Compiler ein int als 32 bit definieren. In den meisten Fällen reicht diese Vermutung aus. Man braucht ja nicht in jeder Codezeile eines Projektes einen genaue Breite, oder? Das braucht man meistens nur an bestimmten wenigen Codestellen.

Und wer doch in einem Projekt eine genaue Breite braucht... der muß dann halt auf <limits> oder typedef zugreifen.

Und wenn man mal auf nen exotischen Compiler portiert, der alles anders macht, dann hat man eh ein Problem.
Machst du dir jetzt ne Birne, nur weil du das hier gelesen hast? Oder amchst du dir ne Birne, weil du in einem konkreten Projekt stehst, wo das wichtig ist? Ich würde mir doch keine Rübe machen, wenn ich davon garnicht betroffen bin. Ich wette, die meisten C++-Coder brauchen sich keine Rübe drüber machen. Weil sie meistens Highlevel programmieren. Und wenn mal der Fall eintritt... ja, dann gibts definitiv Lösungen!!!

Nexus

BarnieGeroellheimer schrieb:

Man braucht ja nicht in jeder Codezeile eines Projektes einen genaue Breite, oder? Das braucht man meistens nur an bestimmten wenigen Codestellen.

Nicht ganz. Meistens rechnet man bei einem int nicht damit, dass er bei 32k bereits aufhört. Und das ist wohl nicht die Ausnahme im Code.

BarnieGeroellheimer schrieb:

Machst du dir jetzt ne Birne, nur weil du das hier gelesen hast? Oder amchst du dir ne Birne, weil du in einem konkreten Projekt stehst, wo das wichtig ist? Ich würde mir doch keine Rübe machen, wenn ich davon garnicht betroffen bin. Ich wette, die meisten C++-Coder brauchen sich keine Rübe drüber machen.

Nexus schrieb:

Ich denke, es ist durchaus legitim, sich in den meisten Fällen auf die Standardbreiten zu verlassen...

Was hast du an meinem Satz nicht verstanden?

Nexus schrieb:

BarnieGeroellheimer schrieb:

Man braucht ja nicht in jeder Codezeile eines Projektes einen genaue Breite, oder? Das braucht man meistens nur an bestimmten wenigen Codestellen.

Nicht ganz. Meistens rechnet man bei einem int nicht damit, dass er bei 32k bereits aufhört. Und das ist wohl nicht die Ausnahme im Code.

Aha? Und wann brauchst du int ? Wenn du das Maximum einer Plattform bzw. Compiler brauchst, dann nimm einfach size_t bzw. std::size_t . Wo ist das Problem? Man muß einfach nur wissen, wann man was benutzt.