PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : c++ Wann sind longs 64bit?


mekakic
2010-07-28, 15:36:29
Auf meiner Maschine sind unter Windows / VS ein int gerade 32bit, long 32bit und long long 64bit.

Wenn ich auf eine 64bit Maschine gehe, was ändert sich daran? Wann sind long 64bit? Nach der Definition, die ich früher mal gelesen habe, müßte ein int auf einer 64bit Maschine auch 64bit sind - aber ist das so? Was passiert dann mit long und long long?

Monger
2010-07-28, 15:46:47
Da C++ ja Binärcode ausspuckt, hängt das nicht von der Zielmaschine ab, sondern von deinem Compiler. Wenn dein Compiler sagt: int ist für mich int64, dann ist das auch so.
Das hat dann natürlich zur Folge, dass dein Kompilat auf einer 32Bit Maschine nicht mehr ausführbar ist.

Bei den managed Sprachen ist das ein bißchen komplizierter. Dort ist ein int erstmal nur ein int. Was für ein int, bestimmt sich dann auf dem Zielrechner. Wenn du 32 bzw. 64 Bit erzwingen willst, musst du auch die dazu passenden Datentypen nutzen, wie z.B. int64.

Ectoplasma
2010-07-28, 15:51:46
Nach der Definition, die ich früher mal gelesen habe, müßte ein int auf einer 64bit Maschine auch 64bit sind - aber ist das so?

Nein das ist nicht so. Auf Windows 64Bit hat ein int und auch ein long immer noch 32Bit. Siehe einmal hier (http://en.wikipedia.org/wiki/64-bit) den Abschnitt "Specific C-language data models".

Wenn du einen Datentypen brauchst, der der jeweiligen Bitbreite einer Plattform entspricht, dann nimmst du size_t. Leider gibt es diesen im Standard nicht mit Vorzeichen.

Neomi
2010-07-28, 16:00:53
size_t mit Vorzeichen -> ptrdiff_t

Coda
2010-07-28, 16:53:47
int: Unix 32 bit, Windows 32 bit
long: Unix 64 bit, Windows 32 bit
long long: Unix 64 bit, Windows 64 bit

http://en.wikipedia.org/wiki/64-bit#Specific_C-language_data_models

Wenn es wirklich wichtig ist, dann verwende beispielsweise boost::int64_t

Bei den managed Sprachen ist das ein bißchen komplizierter. Dort ist ein int erstmal nur ein int. Was für ein int, bestimmt sich dann auf dem Zielrechner.
Red kein Blech. int ist in Java und C# immer 32 bit, long 64 bit. Sonst wäre das ganze in etwa so portabel wie ein Atombunker.

Monger
2010-07-28, 19:10:58
Red kein Blech. int ist in Java und C# immer 32 bit, long 64 bit. Sonst wäre das ganze in etwa so portabel wie ein Atombunker.
Hast Recht. Keine Ahnung, wie ich auf den Trichter komme. Hab da vermutlich an IntPtr (http://msdn.microsoft.com/de-de/library/system.intptr(VS.80).aspx) gedacht.

Gast
2010-07-28, 20:10:25
Das sollte man nicht durcheinander bringen:

1.) Was sich an einem 64Bit System ändert ist lediglich die Länge der Adressen d.h. die Pointer sind 64Bit lang. Auf einem 32Bit System sind diese 32Bit lang und auf einem 16Bit System 16 Bit. Solange man nicht mit Pointerarithmetik herumpfuscht, sollte das jedoch egal sein.

2.) Bei einer Verbreiterung des Adressbereichs war es bisher immer auch der Fall, dass in der CPU auch die Register verbreitert wurden, da ein Großteil der Operationen Adressoperationen sind und wenn diese nicht in einem Zyklus durchgeführt werden können, dann würde das enorm bremsen. Das ist auch ein Mitgrund des Performanceschubs in x64 Software unter manchen Anwendungen. Das hat aber vom Konzept her nicht zwingend etwas mit der Adressierung zu tun. Es wäre genauso möglich den x86 Befehlssatz so zu erweitern, dass 64Bit Integer in einem Zug berechnet werden können. Etwas ähnliches hat man z.B. mit den SSE Befehlen gemacht.

3.) Wie breit eine Variable vom Datentyp int ist, das hängt nur vom Compiler ab, in welchen Maschinencode dieser den C Code übersetzt und sonst gar nichts. Bei 16Bit Systemen war es noch üblich, dass ein int nur 16Bit ist, ein long 32 Bit und ein long long 64 Bit. Das hat den Grund gehabt, dass kleine Zählervariablen als 16Bit ausreichend waren und 32Bit einen höheren Rechenaufwand erfordert hätten. long und long long waren dazu da, um 32 bzw. 64Bit integer anzulegen.
Bei der Umstellung haben die Compiler meistens den normalen int auf 32Bit ausgelegt, da kein Performanceverlust mehr vorhanden war. Laut AMD Software Optimization Guide ist der Performance bei 32Bit sogar höher, solange genug Speicher vorhanden ist, da die Register nicht teilweise niedergenullt werden müssen. Ein long ist immer noch 32 Bit und ein long long 64 Bit. Das bezieht sich jedoch nur auf die meisten C Compiler. In VBA ist ein Integer z.B. immer noch 16 Bit, auch wenn das Office auf einem 64Bit System läuft.
Bei der Umstellung auf 64 Bit, wurde hier jedoch nichts mehr geändert, da man erstens die Kompatibilität weitgehend erhalten wollte und zweitens in den meisten Fällen 32Bit mehr als genug sind.

4.)
In .NET ist man die Sache gleich ganz anders angegangen und hat die Datentypen Int8, Int16, Int32 und Int64 definiert. Das Ganze gibt es noch einmal als UInt, auch wenn es nicht CLS konform ist.
Den klassichen int (C#) bzw. Integer (VB.NET) gibt es immer noch, jedoch ist das nur ein anderer Namen für Int32.

Ein .NET Programm besteht jedoch nicht aus Maschinencode. Dieser wird erst zur Laufzeit vom Zielsystem generiert in Abhängigkeit vom System (x86 oder x64, mit SSE Unterstützung oder ohne etc.) Man kann zwar einem Programm sagen, dass es nur für x86 oder x64 compiliert wird, aber normalerweise lässt man das offen.

Coda
2010-07-28, 20:43:48
Etwas ähnliches hat man z.B. mit den SSE Befehlen gemacht.
Da muss man aber schon mehr als eine Auge zukneifen um das als ähnlich zu betrachten.

Gast
2010-08-02, 14:43:20
Was ist in VC++ der Datentyp für 128 Bit unsigned integer (auf AMD64-Plattformen)?

Neomi
2010-08-02, 15:13:14
128 Bit Integer sind kein Bestandteil von C/C++. Wenn du damit rechnen willst, dann benötigst du eine Bignum Library oder mußt dir selbst eine schreiben.

Gast
2010-08-02, 15:16:23
Aber 64-Bit-Integer sind Bestandteil von VC++ für 32-Bit-Code, warum dann nicht 128 Bit für 64-Bit-Code?

Coda
2010-08-02, 15:44:38
Weil man's im Normalfall einfach nicht braucht vermutlich.

Benutz einfach die GNUMP mit dem C++-Wrapper dazu. Funktioniert wunderbar.