int oder INT

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.