int oder INT

groovemaster

f.-th. schrieb:

also ausser den ms-compilern kommt mindestens der free bcc5.5 mit INT und int
klar.

Kann ich nicht bestätigen.

Undefined symbol 'INT' in function main()

getestet mit Borland C++ 5.5.1 Compiler

f.-th. schrieb:

artchi schrieb ( 2. beitrag) der wertebereich von INT ist bei den ms-compilern
ist gleich egal ob 16, 32 oder 64 -bit compiler - int ist aber "bit-gebunden".

Weiss zwar nicht, was du mit "bit-gebunden" meinst, aber INT war schon immer ein int Alias (afaik). Unter DOS (16 Bit) war int auch 16 Bit, unter Win32 und Win64 ist int 32 Bit gross. So gross ist das Chaos also gar nicht.

f.-th. schrieb:

habe mal vor einiger zeit einen dbase3-headerstruct (geschrieben für 16bit)
mit sizeof(headergrösse) gecheckt: ergebnis je nach compiler 32 bis 37 byte
gross! ursache asser int( 16 oder 32 bit)

Für sowas nimmt man eben spezielle typedefs, zB int32. Damit ist sichergestellt, dass unabhängig von Compiler oder Plattform der Typ immer gleich gross ist. Zudem sollte man auf Alignment achten.

@groovemaster: ich hab meine c/c++ compiler auf einem anderen rechner.
deswegen kann ich jetzt nicht meine sub-sub-version (bcc5.5.?) nachsehen
aber windows-headerfile einbinden und dann INT no errors und no warnings.
oder hast du mit deinem bcc5.5 noch keine windows-api-exe erstellt?

und zur grösse von int 16-bit-umgebung ist klar, 32-bit auch noch aber bei
64-bit soll es nach den info's aus dem netz so sein das einige compiler
meinen int sei 32 bit und andere int sei 64 bit.

und zur dbase3-header-struct: ich wollte weitgehend compiler-unabhängige
quelltexte erstellen, denn welcher 16-bit-compiler kennt schon int32, da
eignet sich schon eher short.

aber das eigentliche problem waren die unterschiedliche interpretation
von char im selben quelltext mit dem selben compiler(verschiedene hersteller
zeigten diesen effect).
aber ich hab's inzwischen nachgelesen char ist mindestens 8bit breit, kann
z.b. auf 32bit systemen auch 16bit oder 32bit breit sein. jenach position
im quelltext wird dies von 32bit systemen entsprechend interpretiert. ich
hab das system noch nicht erkannt. andere getestete compilerschalter brachten
noch keinen erfolg. vielleicht find ich ja noch die passende kombination.

mfg f.-th.

nillable

f.-th. schrieb:

aber windows-headerfile einbinden und dann INT no errors und no warnings.

Also unterstützt der Compiler nicht INT, sondern typedef.

groovemaster

f.-th. schrieb:

aber windows-headerfile einbinden und dann INT no errors und no warnings.

Compilerunterstützt bedeutet immer nativ, also ohne externe Definitionen. Wenn du irgendwelche Headerdateien einbindest, dann ist klar, dass dem Compiler der Typ dadurch bekannt ist. Das ist bei anderen Compiler naber genauso.

f.-th. schrieb:

und zur grösse von int 16-bit-umgebung ist klar, 32-bit auch noch aber bei
64-bit soll es nach den info's aus dem netz so sein das einige compiler
meinen int sei 32 bit und andere int sei 64 bit.

Das könnte vermutlich von Plattform zu Plattform unterschiedlich sein. Mir ist bisher lediglich bekannt, dass sich unter Windows long von 32 Bit auf 64 Bit vergrössert, alle anderen Ganzzahltypen sollen gleich bleiben.

f.-th. schrieb:

und zur dbase3-header-struct: ich wollte weitgehend compiler-unabhängige
quelltexte erstellen, denn welcher 16-bit-compiler kennt schon int32

Äääähh, so ziemlich jeder DOS Compiler long.
Genauso gut könntest du fragen, welcher 32 Bit Compiler schon int64 kennt? Hey ich kenn einen, GCC. Und noch einen, MSC. Oder wie wärs mit dem DMC? Nahezu jeder aktuelle Compiler kennt long long. OK, ist zwar C, aber idR gibt es Optionen, diesen Typ auch in C++ zu nutzen. Mal ganz abgesehen davon, dass einige Compiler noch eigene Typen mitbringen, zB wie __int64 beim MSC. Vielleicht dürfen wir uns in zukünftigen C++ Standards auch auf sowas wie C's <stdint.h> freuen.
Du siehst, dieser ganze Typendschungel ist ein ziemliches Hick-Hack, aber es geht, wenn man nur will. Und ein int32 für 16 Bit Compiler nachzuschieben ist kein allzu grosses Problem. Wenn long nicht bereits 32 Bit gross ist, dann kann man immer noch zwei int16 nehmen, eines für lo und eines für hi. Du musst halt lediglich entscheiden, was du maximal supporten willst, und dann die Implementation entsprechend darauf ausrichten.

f.-th. schrieb:

aber das eigentliche problem waren die unterschiedliche interpretation
von char im selben quelltext mit dem selben compiler

Sehr unwahrscheinlich. C++ definiert die Grösse von char zwar nicht exakt, aber zumindest soweit, dass ein char so gross wie ein Byte ist. Und ein Byte sollte auf dem jeweiligen Compiler immer gleich gross sein. Sicherlich kann die Grösse eines Bytes von einem zum anderen Compiler unterschiedlich gross sein, aber immerhin gibt es auch mehr Plattformen als nur Windows oder Linux.
Wie ich bereits erwähnte, sind solche Beobachtungen oftmals auf Alignment zurückzuführen. Bsp.

struct foo
{
    char a;
    int b;
};

Gehen wir mal von einem 32 Bit System aus, auf dem char 8 Bit und int 32 Bit gross ist. Wider aller Erwartungen ist es möglich, dass hier ein Compiler für sizeof(foo) nicht 5 ausspucken wird. Warum? Nun, zum einen garantiert der Standard dies nicht. Und zum anderen möchte der Compiler evtl., dass für jeden Member höchstmögliche Zugriffsgeschwindigkeit erreicht wird, weil der Benutzer zB eingestellt hat, auf Geschwindigkeit zu optimieren. Für foo.a ist das ja noch kein grosses Problem, da foo.a ein Byte gross ist, und dies die kleinste adressierbare Einheit ist. Bei x86 CPUs ist es zB egal, an welcher Stelle dieses Byte im Speicher liegt, der Zugriff darauf ist immer gleich schnell (mal abgesehen davon, dass Lesezugriffe idR schneller als Schreibzugriffe sind). Bei foo.b ist es schon etwas schwieriger. Ich will jetzt nicht näher auf die Arbeitsweise von Memory-Pipelines in Verbindung mit der CPU eingehen, das würde zu weit führen. Aber x86 CPUs können zB schneller auf einen 32 Bit Wert zugreifen, wenn er auch an einer 32 Bit (4 Byte) Speichergrenze ausgerichtet ist. Der Compiler definiert diese Struktur dann wie folgt

struct foo
{
    char a;
    char __dummy[3];
    int b;
};

Da für die Struktur selbst dann auch mindestens ein 32 Bit Alignment verwendet wird, ist sichergestellt, dass foo.b immer an einer 32 Bit Grenze ausgerichtet ist.
Dennoch gilt immer, dass sizeof(foo.a) == 1.
Ich kann also deine Aussage bzgl. "unterschiedliche interpretation von char" nicht wirklich nachvollziehen.

f.-th. schrieb:

aber ich hab's inzwischen nachgelesen char ist mindestens 8bit breit, kann
z.b. auf 32bit systemen auch 16bit oder 32bit breit sein.

Nun, wie bereits erwähnt, definiert der Standard keine exakten Grössen. Er sagt lediglich Folgendes:

sizeof liefert die Grösse in Byte
1 == sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

Artchi

grooevmaster! Muß dich leider berichtigen. long wird auf 64bit-System unter Windows weiterhin wie unter Win32 32bit bleiben, das wird sich nicht ändern. Denn da hat sich MS schon lange drauf fest gelegt. long long wird aber 64bit.

Hier die fundamentalen Typen und weiter unten die von MS:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_fundamental_types.asp

Data Type Ranges:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_langref_data_type_ranges.asp

groovemaster

Artchi schrieb:

grooevmaster! Muß dich leider berichtigen. long wird auf 64bit-System unter Windows weiterhin wie unter Win32 32bit bleiben, das wird sich nicht ändern. Denn da hat sich MS schon lange drauf fest gelegt.

Das wäre aber schlecht. Welchen 64 Bit Typ wird es denn dann unter Win64 geben? Immerhin kennt C++ kein long long.

Artchi

Eigentlich gibts ja auch kein long, da long nur für "long int" steht. Ich würde einfach mal sagen, das man unter Windows am besten __int64 benutzt und sich z.B. ein typedef definiert, so das man bei einer Portierung oder anderen Compiler einfach umschalten kann. Also long long meidet aber __int64 indirekt durch ein eigenes typedef benutzt, z.B.:

typedef __int64 long64;

Das SDK von Maxon Cinema4D hat z.B. ein INT64, und die haben auch schon ohne Problem eine Win64-Version von ihrem C4D released. Nur als Beispiel das es irgendwie funktioniert, wenn man will.

Walli

Der Standard nicht, aber nahezu jeder Compiler kennt einen 64 Bit-Typ, also wird man sich ja einen typedefen können. Ich finde u64 bzw. i64 auch schöner als (unsigned) long long.

EDIT: Artchi war Sekundenbruchteile schneller .

groovemaster

So, hab mich jetzt noch mal etwas genauer informiert. Scheint tatsächlich so zu sein, dass Win64 auf das LLP64 Datenmodell setzt. Find ich irgendwie schade. LP64 wäre imo konsequenter gewesen. Zum einen hätte man dann in C++ einen Standard Typ für 64 Bit Integer, und müsste nicht auf irgendwas compiler-spezifisches zurückgreifen. Zum anderen würde man nicht 2 Typen für das Gleiche verschwenden. Irgendwie hab ich das Gefühl, dass es MS Spass macht immer wieder Altlasten mitzuschleppen, anstatt irgendwo einen sauberen Schnitt zu machen. Auch wenn das kurzzeitig vielleicht etwas mehr Aufwand bei Portierungen verursacht.

http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

www.xxl.istgenial.de

groovemaster

why... schrieb:

http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx

Sind für mich nur Ausreden. Was hindert MS denn daran, zB

LONG biWidth;

in

INT32 biWidth;

umzudefinieren, wenn sie wollen, dass die Grösse immer gleich bleibt? Wie bereits erwähnt, bringt das durchaus etwas mehr Arbeit mit sich. Ich tendiere aber eher dazu, Altlasten über Bord zu werfen, anstatt sich damit ständig ein zeitgemässes Design zu verbauen. Und wenn man so einen Schritt nicht bei der Umstellung von der einen zur anderen Bit-Architektur wagt, wann dann?

Ponto

groovemaster schrieb:

Wie bereits erwähnt, bringt das durchaus etwas mehr Arbeit mit sich. Ich tendiere aber eher dazu, Altlasten über Bord zu werfen, anstatt sich damit ständig ein zeitgemässes Design zu verbauen. Und wenn man so einen Schritt nicht bei der Umstellung von der einen zur anderen Bit-Architektur wagt, wann dann?

Warum ist eigentlich deiner Meinung nach LP64 das zeitgemässe Design und nicht LLP64? Ich bin ja froh, dass sich die Unix Welt für LP64 entschieden hat. Aber ich kann eigentlich nicht sagen, warum. Das Gewohnte liegt am besten.

paedubucher

Warscheinlich wollte Mikrigsoft seine Compiler gegen Caps-Lock Fehler absichern:

#define INT int

groovemaster

Ponto schrieb:

Warum ist eigentlich deiner Meinung nach LP64 das zeitgemässe Design und nicht LLP64?

Ich will nicht behaupten, dass LP64 "zeitgemässer" ist. Liegt wahrscheinlich im Auge des Betrachters. Ich find's einfach vorteilhafter, zB aufgrund der bereits erwähnten Punkte.

groovemaster schrieb:

Zum einen hätte man dann in C++ einen Standard Typ für 64 Bit Integer, und müsste nicht auf irgendwas compiler-spezifisches zurückgreifen. Zum anderen würde man nicht 2 Typen für das Gleiche verschwenden.

Weitere Sachen, wie Portabilität, Kompatibilität, Performance, etc.pp kann ich momentan natürlich nicht abschätzen. Aber es wird schon was an LP64 dran sein, wenn sich einige grosse Firmen dafür ausgesprochen haben.