Bitgrößen von Datentypen

Hi,

ich stehe vor folgendem Problem, um mein Programm möglichst protabel zu halten muss ich diverse datentypen per präcompiler definieren damit sie überall vorhanden sind, ist ja kein problem, nur bei einigen wirds ein problem.

es gibt folgende typen auf dem MS Compiler aber nicht auf dem GCC:

__int8
__int16
__int32
__int64

__int8 ist ein char, das ist klar
jedoch die anderen? Ich habe gelesen das int auf manchen Betriebssystemen 32 und auf anderen 64 Bit groß ist! Also Plattformabhängig! Gibt es typen wie char die nicht plattformabhängig sind und womit ich die anderen 3 Datentypen emulieren kann?

Bashar

char ist auch plattformabhängig, und hat CHAR_BIT Bits (#include<climits>)

ich dachte char müsste überall 8 bit sein, da es die kleinste einheit ist und nur 256 Zeichen groß ist?

fragen wir mal so... welche zusammenstellung von datentypen würde denn genau 8,16,32 und 64 bit ergeben?

Erhard Henkes

char = 1 Byte [EDIT] oder mehr, s.u. [/EDIT]
char <= short
short <= int
int <= long

int entspricht der "Maschinenbreite", also wird es auf 64bit anwachsen.

Du kannst eine header-Datei schreiben, in der du typedefs ablegst, die du dann zentral dem jeweiligen System anpasst, so wie WinAPI das mit BYTE, WORD, DWORD, QWORD macht.

japro

*** schrieb:

ich dachte char müsste überall 8 bit sein, da es die kleinste einheit ist und nur 256 Zeichen groß ist?

soviel ich weiss muss char nur mindestens 8 bit haben... darf aber mehr haben

Erhard Henkes

Im Standard wird char und die anderen Integer wie folgt beschrieben:

Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set. If a character from this set is stored in a character object, the integral value of that character object is equal to the value of the single character literal form of that character. It is implementationdefined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types.
In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementationdefined. There are four signed integer types: “signed char”, “short int”, “int”, and “long int.” In this list, each type provides at least as much storage as those preceding it in the list. Plain ints have the natural
size suggested by the architecture of the execution environment; the other signed integer types are provided to meet special needs.
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,” each of which occupies the same amount of storage and has the same alignment requirements (3.9) as the corresponding signed integer type; that is, each signed integer type has the same object representation as its corresponding unsigned integer type. The range of nonnegative values of a signed integer type
is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same.

Daher könnte char nach dem Standard auch durch mehr als 8 bit dargestellt werden.

net 0

Erhard Henkes schrieb:

Im Standard wird char und die anderen Integer wie folgt beschrieben:

Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set...

Daher könnte char nach dem Standard auch durch mehr als 8 bit dargestellt werden.

diese 'shall' ist aber kein 'must'
d.h. char könnte auch kleiner sein, z.b. 5 bits oder sowas. erst recht, wenn das system nur einen eingeschränkten zeichensatz hat (nur grossbuchstaben oder so).
ich halte die idee mit den unterschiedenen typedefs für die beste, also:
#ifdef __MY_COOL_SYSTEM__
typedef unsigned long UINT16;
...
...
#elif __WINDOOFS__
typedef unsigned long UINT32;
...
...
#endif

HumeSikkins

net schrieb:

Erhard Henkes schrieb:

Im Standard wird char und die anderen Integer wie folgt beschrieben:

Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set...

Daher könnte char nach dem Standard auch durch mehr als 8 bit dargestellt werden.

diese 'shall' ist aber kein 'must'

Doch im Endeffekt ist es genau das. Über ein "shall" kann nicht diskutiert werden. Wenn da steht "shall have X", dann muss eine Implementation X haben sonst ist sie nicht standardkonform. Steht da "shall not have X", dann darf es kein X geben.

.h. char könnte auch kleiner sein, z.b. 5 bits oder sowas

Nein können sie nicht. Der C++ Standard enthält den C-Standard "by reference" und im C-Standard steht, dass CHAR_BIT *at least* 8 sein muss. Nicht 5, 3 oder 7.

Erhard Henkes schrieb:

int entspricht der "Maschinenbreite", also wird es auf 64bit anwachsen.

Nein, das stimmt so auch nicht. int wird wohl 32 Bit bleiben.

Shlo

net schrieb:

ich halte die idee mit den unterschiedenen typedefs für die beste, also:
#ifdef __MY_COOL_SYSTEM__
typedef unsigned long UINT16;
...
...
#elif __WINDOOFS__
typedef unsigned long UINT32;
...
...
#endif

Ja, aber bitte nicht großgeschrieben:

typedef unsigned short uint16_t;
typedef unsigned uint32_t;
typedef /*implementation-defined*/ uint64_t;

so das die Namensgebung der size_t Konvention folgt

Erhard Henkes

Nein, das stimmt so auch nicht. int wird wohl 32 Bit bleiben.

Woher nimmst du diese Verweigerungshaltung gegen den Fortschritt?
Nach 16 bit kam 32 bit, und jetzt folgt 64 bit, und dann kommt 128 bit, ... .

Das liegt nicht an meiner Verweigerungshaltung, sondern an der der Compilerhersteller.
Zumindest für den VC++ kann ich es dir sicher sagen. Aber der long wird 64 Bit, das ist doch auch schon mal was wert. Jetzt hat long auch eine Daseinsberechtigung. Und endlich trägt er seinen Namen zurecht.

interpreter

Was genau bestimmt eigentlich, wie groß z.B. ein int ist? Compiler & Betriebssystem & CPU ?

Eigentlich nur der Compiler und wie man ihn einstellt, IMHO. Der kann ja auch auf nem 256 Bit - Prozessor Code generieren, bei dem ein int nur 32 Bit ist.
Siehst ja auch in Java, da ist ein int auch immer 32 Bit, das wird schon so übersetzt, dass das auch auf nem Handy so ist.

net 0

HumeSikkins schrieb:

net schrieb:

diese 'shall' ist aber kein 'must'

Doch im Endeffekt ist es genau das. Über ein "shall" kann nicht diskutiert werden. Wenn da steht "shall have X", dann muss eine Implementation X haben sonst ist sie nicht standardkonform. Steht da "shall not have X", dann darf es kein X geben.

also ich kenn' das von den rfc's. da bedeutet 'shall' oder 'should' soviel wie 'wär schon ganz gut, muss aber nicht' während ein 'must' absolut verpflichtend ist.

HumeSikkins schrieb:

..im C-Standard steht, dass CHAR_BIT *at least* 8 sein muss.

na, das ist wenigstens eindeutig. ich wundere mich nur, warum die verfasser solcher dokumente wichtige informationen über den ganzen text verstreuen, so daß man sich alles zusammenpuzzlen muss.

Erhard Henkes schrieb:

....und jetzt folgt 64 bit, und dann kommt 128 bit, ... .

was aber keinen grossen praktischen nutzen mehr hat. wird wohl nur aus marketing-gründen gemacht. warum soll man für schleifenzähler 16 bytes verschwenden? ein größerer adressbus wär schon sinvoller.

Bashar

net schrieb:

also ich kenn' das von den rfc's. da bedeutet 'shall' oder 'should' soviel wie 'wär schon ganz gut, muss aber nicht' während ein 'must' absolut verpflichtend ist.

Abgesehen davon, dass should und shall schon ein großer Unterschied ist (should ist Konjunktiv): Im C++-Standard wird "shall" anscheinend nicht definiert, aber im C99-Standard gibt es einen Absatz dazu:

In this International Standard, shall'' is to be interpreted as a requirement on an implementation or on a program; conversely,shall not'' is to be interpreted as a
prohibition.

Walli

net schrieb:

Erhard Henkes schrieb:

....und jetzt folgt 64 bit, und dann kommt 128 bit, ... .

was aber keinen grossen praktischen nutzen mehr hat. wird wohl nur aus marketing-gründen gemacht.

Ja ja, ich wette das haben die damals auch über 32 Bit gesagt .

randa

Hier mal die Größen auf einem 64 Bit System in Bits:

char: 8
short int: 16
int: 32
long int: 64
float: 32
double: 64
long double: 128	//!

Alle Zeiger: 64

HumeSikkins

net schrieb:

HumeSikkins schrieb:

net schrieb:

diese 'shall' ist aber kein 'must'

Doch im Endeffekt ist es genau das. Über ein "shall" kann nicht diskutiert werden. Wenn da steht "shall have X", dann muss eine Implementation X haben sonst ist sie nicht standardkonform. Steht da "shall not have X", dann darf es kein X geben.

also ich kenn' das von den rfc's. da bedeutet 'shall' oder 'should' soviel wie 'wär schon ganz gut, muss aber nicht' während ein 'must' absolut verpflichtend ist.

Ja ich kenn' das von meiner Humpty-Dumpty-Gruppe. Dort bedeutet "grün" oder "Gras" immer das was uns gerade gefällt.
Dir ist aber schon klar, dass "shall" und "should" zwei unterschiedliche Wörter sind? Erkennt man z.B. an der unterschiedlichen Schreibweise.

Bashar schrieb:

Im C++-Standard wird "shall" anscheinend nicht definiert, aber im C99-Standard gibt es einen Absatz dazu:

In this International Standard, shall'' is to be interpreted as a requirement on an implementation or on a program; conversely,shall not'' is to be interpreted as a
prohibition.

Eine solche Definition ist natürlich am Besten. Auf der anderen Seite denke ich mal, dass ein Mensch der genug Englisch beherrscht um einen Standard zu lesen auch die Bedeutung von "shall" kennen sollte.
In der Bibel steht vor den Zehn Geboten ja auch keine Definition von shall.
Da steht einfach "You shall not steal" und jeder weiß, dass damit nicht gemeint ist "Also wär schon gut, wenn du nicht stehlen würdest. Kannste aber natürlich trotzdem machen".

DEvent

naja da steht aber vorher das das ein gebot ist, und ein gebot ist ja sowas wie ein befehl, und über befehle diskutiert man nicht ( normalerweise )

net 0

HumeSikkins schrieb:

Eine solche Definition ist natürlich am Besten. Auf der anderen Seite denke ich mal, dass ein Mensch der genug Englisch beherrscht um einen Standard zu lesen auch die Bedeutung von "shall" kennen sollte.

also mein papa kommt aus amiland und als kind hab' ich fast nur english gesprochen aber vielleicht hapert's bei mir eher, das vernünftig ins deutsche zu überführen. für mich drücken diese wörter 'shall', 'should', 'must' eine unterschiedliche stärke aus.
beispiel:
should - ich sollte die menschheit vernichten, weils irgendwie besser ist
shall - ich soll die menschheit vernichten, weil das mein auftrag ist
must - ich muss die menschheit vernichten, ich habe keine andere wahl

HumeSikkins schrieb:

In der Bibel steht vor den Zehn Geboten ja auch keine Definition von shall.
Da steht einfach "You shall not steal" und jeder weiß, dass damit nicht gemeint ist "Also wär schon gut, wenn du nicht stehlen würdest. Kannste aber natürlich trotzdem machen".

klar kannstes machen. dann bist du halt kein anständiger christ und gottes zorn wird furchtbar sein.

Bashar schrieb:

Im C++-Standard wird "shall" anscheinend nicht definiert, aber im C99-Standard gibt es einen Absatz dazu:

In this International Standard, shall'' is to be interpreted as a requirement on an implementation or on a program; conversely,shall not'' is to be interpreted as a
prohibition.

solche definitionen sind absolut wichtig für diese standards. damit wird wieder alles klar und das 'shall' wird somit ein 'must'.