32bit->64bit und die datentypen
-
ja, mal wieder so ein intelligenter name, hätte auch "orangensaft" schreiben sollen
.
also, wie ihr ja alle wisst, wird es "bald" einen massiven schwenk von 32 auf 64 bit auf dem pc markt geben(ist ja atm schon im gange).
die frage ist nun, wie man den programmcode darauf vorbereiten kann, ein int kompiliert auf einer 32Bit maschine ist was andres als ein int kompiliert auf einer 64bit maschine(mit maschine mein ich pc+betriebssysten), und der code wird wohl noch mehrere jahre beide sachen unterstützen müssen, sodass man eine 32bit und 64bit version des programms braucht.ich hab etwas drüber nachgedacht, und kam auf folgenden ansatz(noch nicht ganz fertig)
typedef typlist4(char,short,int,long) signedTypes; typedef typlist2(float,double) realTypes; typedef typlist4(unsigned char,unsigned short,unsigned int,unsigned long) unsignedTypes; //hab ich schon erwähnt, dass das da oben macros sind?darum brauch man macros :) //um ein element aus den typlisten zu bekommen template<class list,int pos> struct getType; template<class head,class tail,int pos> struct getType<typlist<head,tail>,pos>{ typedef getType<tail,pos-1>::type type; }; template<class head,class tail> getType<typlist<head,tail>,0>{ typedef head type; }; template<class list> getType<list,-1>{ typedef nulltype type; //alternativ könnte hier ein boost::static_assert rein,ist immerhin ein fehler }; template<int pos> getType<nulltype,pos>{ typedef nulltype type; //alternativ könnte hier ein boost::static_assert rein,ist immerhin ein fehler }; template<> getType<nulltype,0>{ typedef nulltype type; //kein fehler... } template<class list,template<class> class boolExpr> struct getPos; template<class head,class tail> struct getPos{ enum{pos=boolExpr<head>::value?0:1+getPos<tail,boolExpr>::pos}; }; template<class typeList,int size> class Type{ private: template<class T> struct hasSize{ enum{value=sizeof(T)==size}; }; public: typedef getType<typeList,getPos<typeList,hasSize> >::type type; //hier weis ich nicht, ob man Type<typeList,size>::hasSize schreiben //muss, oder ob das so reicht }; typedef Type<signedTypes,4> INT;
naja, etwas viel code^^
wie löst ihr in euren projekten das problem?
-
Welches Problem hast du denn genau? Ich habe keins. Du hast nur Probleme, wenn du dich darauf verlässt, dass long 32 Bit hat (das sei jetzt mal so, ich weiß, dass das Plattformabhängig ist), dass ein Pointer 32Bit hat und somit in ein int gecastet werden kann (soll ja Leute geben, die sowas lustig finden), oder dass size_t 32 bit hat.
wenn du keine dieser Annahmen machst, solltest du keine großen Probleme haben. Wenn du wirklich annahmen über die Größe machst, solltest du dazu eh die sized-Typen benutzen (z.B. von boost oder vom VC++), die ändern sich natürlich nicht.
-
ich muss mich auf die größe verlassen können, wenn ich einen int aus ner datei lesen will
-
int sollte gleich bleiben, zumindest mal jetzt für normale PCs. Dafür wird long mal einen Sinn haben.
Ist aber wie gesagt IMHO der falsche Denkansatz. Wenn du auf eine bestimmte Größe angewiesen bist, dann benutze spezielle Typen, die eine bestimmte Größe haben.
Damit hast du absolute Sicherheit und kennzeichnest im Code obendrein "das Ding muss 32 Bit haben".
-
naja, dann konnte ich wenigstens einmal mit meinem wissen über meta programmierung prollen
aerrgh wieso schreib ich eigentlich immer soviel code, weil ich denke, sowas gibet nicht, und 2 mins später kommt jemand vorbei und sagt "jo gibet schon lange"
-
Weil du dich nicht vorher ausreichend informierst, ob es das schon gibt. Zumindest boost muss man sich schon erstmal ansehen.
-
wenigstens kann man seinen horizont etwas erweitern(btw, meine idee find ich immernoch nicht so schlecht :D)
ps: kann mir mal einer erklären, wieso meine eine hand immer schneller schreibt als die andere? das nervt hochgradig
-
Das macht nciht wirklich sinn oder? Ich beziehe mich auf:
typedef Type<signedTypes,4> INT;
Wenn dann:
typedef Type<signedTypes,4>::type INT;
Und du scheinst gar keine Regel bezütlich groß und kleinschreibung zu haben. Mal werden Typen komplett klein geschrieben, mal beginnen sie mit einem Großbuchstaben, mal komplett groß.
-
also dass int auf 32 bit bleibt ... waer ich mir ned so sicher.
die definition sagt, mindestens 16 bit ...
und da alle den int traditionsgemaess als "schnellen" Datentyp verwenden, wuerde es gar Sinn machen, den auf den Registerwert mitanzuheben ....@otze
Naja, nen logistisches Problem bekommst soweiso ....
dein Programmm schreibt binaere daten, zum beispiel.
Auf ner 64 bit plattform hauts pro int 8 byte auf die pladde, bei nem 32 bit system 4 byte. Sprich deine Dateien sind nimmer kompatibel ....
Die Datenbreite irgendwo in der Datei festhalten, machen wohl die wenigsten
Also, entweder du machst das was Optimizer vorschlaegt, und verwendest fest definierte Typen (INT32, INT64 unter windoof z.b.)
oder du weichst auf nichtbinaere Dateiformate (XML) aus ...viel Spass
Ciao
-
also dass int auf 32 bit bleibt ... waer ich mir ned so sicher.
die definition sagt, mindestens 16 bit ...
und da alle den int traditionsgemaess als "schnellen" Datentyp verwenden, wuerde es gar Sinn machen, den auf den Registerwert mitanzuheben ....Für den VC++ ist es auf jeden Fall schon mal sicher so. Wäre auch unlogisch, es anders zu machen als Java und C#, insbesondere, da man C++ und C# Code mischen kann, wäre das _sehr_ verwirrend.
Ich glaube auch, dass die meisten anderen Compiler da mitziehen werden.
-
otze schrieb:
ich muss mich auf die größe verlassen können, wenn ich einen int aus ner datei lesen will
Wieso?
Für 32Bit und 64Bit muss man die Programme doch neu kompilieren. Und sofern kein Dateiaustausch zwischen 32Bit Version und 64Bit Version stattfindet, brauchst das doch also nicht ?
-
D.h. also, dass jede Webseite ihre JPEGs in einer 32bit- und einer 64bit-Version anbieten soll. Am besten noch Big Endian/Little Endian.
Und dass 64bit-Warcraft keine Savegames geschweige denn Datenfiles der 32bit-Version verwenden kann.
Nicht grad sehr praktisch.
int hat auf allen 64bit-Compilern, die mir bekannt sind, 32 Bit. Das sind gcc (AMD64), Compaq (Alpha), Intel (Itanium), MSVC (Itanium), SGI (MIPS).
-
Welches 64Bit Warcraft? Gibts net. Aber würde es eins geben, würden die entweder wie vorgeschlagen fixe Größen verwenden, oder die Datei konvertieren. Wobei wohl eher das erstere der Fall sein wird, da sonst im Multiplayer Speicherstände nicht mehr über Hashs auf Gleichheit überprüft werden könnten.
Und was hat JPEG jetzt damit am Hut? Natürlich gibts die Bilder nur in einer Version?
-
Helium schrieb:
Das macht nciht wirklich sinn oder? Ich beziehe mich auf:
typedef Type<signedTypes,4> INT;
Wenn dann:
typedef Type<signedTypes,4>::type INT;
ja, der letzte teil war einfach nur da um das ganze zu kompletieren, ist mir wohl ein kleiner ausrutscher unterlaufen, hab ja auch keinen anspruch auf absolute richtigkeit erhoben, sondern schon von vonherein gesagt,d ass es noch nicht fertig ist(vielleicht sag ich auch das nächste mal einfach "noch nicht kompiliert^^").
Und du scheinst gar keine Regel bezütlich groß und kleinschreibung zu haben. Mal werden Typen komplett klein geschrieben, mal beginnen sie mit einem Großbuchstaben, mal komplett groß.
ja mein hauptproblem, eigentlich fangen funktionen bei mir klein an, und Klassen zur unterscheidung groß, ich vergess es nur manchmal einfach, und hinterher ärgere ich mich^^. kommt imho auch daher, da ich früher alles am anfang klein hatte, und der mensch ist halt ein gewohnheitstier(nichts destotrotz ist das was ich gemacht habe nicht richtig :().
@Lars was eine erkenntnis "um dateien auszulesen braucht man fixe größen", sorry, aber das hatten wir hier schonmal
und wegend er sache mit dem jpeg, das bezog sich auf diese aussage:
Für 32Bit und 64Bit muss man die Programme doch neu kompilieren. Und sofern kein Dateiaustausch zwischen 32Bit Version und 64Bit Version stattfindet, brauchst das doch also nicht ?
bei biledern findet automatisch ein datenaustausch statt^^