PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Integer mit gleicher Größe wie Zeiger?


zeckensack
2005-11-22, 01:24:47
Portabel?

AFAIK ist in allen MSVC-Versionen, 64Bit-Ziel oder nicht, long int 32 Bit groß und long long int 64 Bit groß. Egal für was man sich entscheidet, man kann einen void* nicht zu einem dieser Typen und wieder zurück casten, ohne um Probleme zu betteln.

Wie sieht's mit size_t aus?

Grob gesagt suche ich einen Integertyp (am liebsten Vorzeichenlos), der auf 32 Bit-Zielen 32 Bit groß ist und auf 64 Bit-Zielen 64 Bit. Gibt's das?
(VC2005 Express liegt neben mir, wird aber vorerst noch nicht installiert)

Und überhaupt ... wo bleibt eigentlich mein 64 Bit-MinGW-GCC!? Und warum unterstützt eigentlich niemand compile time assertions?

Coda
2005-11-22, 01:50:51
Darf man fragen wozu du das brauchst?

zeckensack
2005-11-22, 02:50:50
Darf man fragen wozu du das brauchst?Ich habe in altem Code gewühlt, und dabei in einem Speicherallokator gesehen, dass ich void* zu unsigned int und zurück caste um Zeigerarithmetik zu machen.

Die saubere Lösung wäre gewesen, stattdessen zu ubyte* zu casten, aber irgendwie interessiert's mich jetzt trotzdem. Zumal so ein großer Intertyp auch ohne unsaubere casts gebraucht wird, sobald Objektgrößen >=4GiB (oder bei diversen Schranz-Compilern auch >=2GiB) auf den entsprechenden Systemen unterstützbar sein sollen. Oder wie drückst du die Größe eines 5GiB großen Speicherblocks aus?

In der VBO-Spec wurde das Problem (?) ebenfalls behandelt, und hat dort zur Einführung zwei neuer Typen geführt, die meinen Kriterien wohl entsprächen (GLsizeiptrARB, GLintptrARB), nur fragte ich mich ob es nicht auch ohne Präprozessor und typedefs Compilerunabhängig schon solche Typen gibt.

ScottManDeath
2005-11-22, 03:52:06
Mhmm ich nehm size_t. Sollte dem entsprechen was Du suchst. Kann's nicht quoten wo das steht, sollte aber das richtige sein.

micki
2005-11-22, 07:49:13
wo ist den das problem? mach dir nen typedef und den kannst du dann auf jedem system auf die gewünschte bitlänge als int definieren. jedenfalls machen das sonst alle so wenn sie portablen code schreiben. *wunder*

Demirug
2005-11-22, 09:16:08
Korrekt wäre uintptr_t. Ich weiß allerdings nicht in wie weit das schon von allen Compiler unterstützt wird.

zeckensack
2005-11-22, 09:36:03
wo ist den das problem? mach dir nen typedef und den kannst du dann auf jedem system auf die gewünschte bitlänge als int definieren. jedenfalls machen das sonst alle so wenn sie portablen code schreiben. *wunder*Mal angenommen ich wollte einen Codeschnipsel einfach mal aus einem größeren Projekt rausnehmen und verschenken oder sonstwie weitergeben, will ich
a)nicht immer meine fünf typedefs dazuknallen müssen, zumal die auch schonmal mit fremden typedefs kollidieren können (zB habe ich meine Windows-Header umgeschrieben, weil die MS-Vollspacken das byte (falsch) definiert haben).
b)nicht zu hören bekommen dass das auf 'nem 64 Bit-System nicht funktioniert.

Es wäre eben schöner wenn es einen "built in" Datentyp geben würde. Wenn es ihn nicht gibt, habe ich eben Pech, wenn doch ... siehe Fred.

Korrekt wäre uintptr_t. Ich weiß allerdings nicht in wie weit das schon von allen Compiler unterstützt wird.Nicht sehr weit ;(

micki
2005-11-22, 09:55:29
a)nicht immer meine fünf typedefs dazuknallen müssen,

ja, wenn ein header soviel ausmacht...:uroll:


zumal die auch schonmal mit fremden typedefs kollidieren können

dafür gibt es bei c++ namespaces, zudem hat man oft entweder eigene prefixe damit genau das nicht passiert bzw. gibt es quasi-standard typedefs wie u32 U32 s32 S32


b)nicht zu hören bekommen dass das auf 'nem 64 Bit-System nicht funktioniert.

typedefs sollten überall funzen ;)


Es wäre eben schöner wenn es einen "built in" Datentyp geben würde. Wenn es ihn nicht gibt, habe ich eben Pech, wenn doch ... siehe Fred.

klar wäre es schöner wenn es alle typen die man haben möchte schon buildin gebe, aber wenn das so wäre bräuchte man wohl kein typedef bzw anders->es gibt alle nötigen typen und den ganzen rest kann man mit typedefs für sich zusammenstellen. das ganze hat auch schöne seiten, du kannst die datentypen jederzeit global für das project ändern z.b. aus dem pointertyp in einen boost::ptr, für float kannst du eine 3dnow/sse implementierung testweise einbinden (oder deinen gepimpten-ubersingle)

nen standard für alle dinge die schön wären wird es wohl nicht geben, dafür gibt es zuviele plattformen für c.

MfG
micki

zeckensack
2005-11-22, 09:58:07
Mhmm ich nehm size_t. Sollte dem entsprechen was Du suchst. Kann's nicht quoten wo das steht, sollte aber das richtige sein.Da habe ich was interessantes gefunden ...
http://forums.whirlpool.net.au/forum-replies-archive.cfm/419979.html

size_t scheint zumindest für die Microsoft-Compiler schonmal zu passen :)

ScottManDeath
2005-11-22, 16:28:39
Da habe ich was interessantes gefunden ...
http://forums.whirlpool.net.au/forum-replies-archive.cfm/419979.html

size_t scheint zumindest für die Microsoft-Compiler schonmal zu passen :)

Naja, geht auch auf einem GCC unter Machtnix und auch mit *wieauchimmerdasheißenmag* unter MacOS. Da sie C stdlib und die STL das nutzen, gehe ich mal stark davon aus, dass es das ISO Prädikat hat :)