Discussion :

[camboui]

Si j'ai bien lu la doc MS, les diff�rences entre du code 32 bits et 64 bits sont uniquement size_t et ptrdiff_t qui deviennent 64 bis (outre tous les pointeurs bien s�r). Le reste ne change pas, � savoir les "int" et "unsigned int" ainsi que "long" et "unsigned long" reste en 32 bits.

Qu'en est-il des valeurs "implicites", comme les sizeof() ou les enum ?
Par exemple si je fais

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
int i;
i=sizeof(T);//sizeof() -> 64 bits ?

Ne devrait-il pas y avoir un warning ?

Autre question.
Est-ce vrai pour tous les compilateurs 64 bits ? Ou pourrait-il y avoir des probl�mes de compatibilit� ? (� priori je ne ferais jamais de code portable autre que pour Linux, Mac et Windows, du intel quoi).

Merci

EDIT, j'oubliais un d�tail important: peut-on allouer des blocks m�moire de plus de 32 bits (>4Gb), avec par exemple
char *ptr=new char[65536*65536*65536]; ?

[Mac LAK]

Ne devrait-il pas y avoir un warning ?

Pourquoi est-ce qu'il y en aurait un ? sizeof renvoie une taille en "nombre de char", donc pourquoi la taille maximale des entiers devrait-elle jouer le moindre r�le l�-dedans ?
EDIT : lu trop vite. Tu peux avoir un warning "Conversion may lose significant digits" ou �quivalent, cf. dernier point de r�ponse sur size_t. Toutefois, c'est tr�s mal / crade d'affecter le r�sultat d'un sizeof � autre chose qu'une variable de type size_t...

Est-ce vrai pour tous les compilateurs 64 bits ?

C'est li� au C/C++, et non pas � la taille du mot-machine. Donc, oui, �a marche tout le temps en ce qui concerne le sizeof.
Pour les diverses tailles des types standards, je n'ai jamais regard� explicitement ce qui �tait pr�vu je dois dire. C'est soit � voir au cas par cas, soit � blinder via des ent�tes de d�finition de type de taille donn�e / v�rification des tailles des types de base.

Du genre :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
#if (sizeof(int)!=4)
  #pragma error Unsupported "int" size.
#endif

Ou :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
#if (sizeof(int)==4)
  typedef int INT32 ;
#else
  #if (sizeof(long int)==4)
    typedef long int INT32;
  #else
    #pragma error Could not find 32 bits integer type.
  #endif
#endif

Le plus pratique reste quand m�me, je pense, d'utiliser une librairie d'abstraction (POCO ou ACE) qui fera tout �a � ta place, et qui (en plus !) t'apportera directement la portabilit� vers tous les OS support�s par ladite librairie, � peu de choses pr�s.

EDIT, j'oubliais un d�tail important: peut-on allouer des blocks m�moire de plus de 32 bits (>4Gb), avec par exemple
char *ptr=new char[65536*65536*65536]; ?

Affiches "sizeof(size_t)" et tu auras la r�ponse. Si c'est 4, la r�ponse est "non". Si c'est 8, la r�ponse est "oui".

[camboui]

Toutefois, c'est tr�s mal / crade d'affecter le r�sultat d'un sizeof � autre chose qu'une variable de type size_t...

Je vais essayer de retenir �a
Merci.

Le probl�me n'est pas dans les nouveaux d�veloppements.
Mais porter des dizaines de milliers de lignes de code (dont certaines datent de l'�poque 16 bits) �crites par les zillions de personnes qui sont pass�es par l� est au del� de l'usage de librairie r�centes...

[Mac LAK]

Dans ce cas, il faut surtout chercher les sizeof dans le code, voir � quoi ils sont affect�s, et voir si cela a une incidence en modifiant le type source et en laissant ensuite le compilo gueuler en niveau maximal de warnings.

Toutefois, si des bouts de code proviennent du monde 16 bits, je ne saurais trop te conseiller de blinder tes fichiers � coup d'ent�tes de v�rification des tailles / types comme je te l'ai mis en exemple ci-dessus.

[camboui]

Voici le genre de code simple qui compile et ne g�n�re aucun warning:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
std::string s;
 
...
 
//genre de ligne probablement déjà modifiée lors du passage 16->32 bits:
unsigned short u=reinterpret_cast<unsigned short>(s.length());
fwrite(f,&u,sizeof(u));

Bref, pas toujours �vident de d�cider ce qu'il faut faire. Surtout si on veut conserver la compatibilit� avec des fichiers binaires existants dans lesquels on a s�rialis� plein de valeurs 16 bits.

[Mac LAK]

Ben forc�ment, avec un cast... Ceci �tant dit, tu peux, comme je te l'ai dit, chercher sizeof dans le code et regarder l'impact.

De toutes fa�ons, un bon portage devrait, normalement, v�rifier un maximum de ligne de code si le programme n'est pas bas� int�gralement sur une librairie d'abstraction.

[3DArchi]

Pour les diverses tailles des types standards, je n'ai jamais regard� explicitement ce qui �tait pr�vu je dois dire.

C'est du sp�cifique � l'impl�mentation. Les seules choses d�finis par le standard sont sizeof(char)=1<=sizeof(short)<=sizeof(int)<=sizeof(long)(<=sizeof(long long) en C++0x) ainsi que les min repr�sentables de chacun de ces types. Ensuite chaque compilo/plateforme a le choix des tailles effectives de ces types.
A noter que sizeof(char)=1 ne veut pas dire 1 octet, mais que la valeur de sizeof(char) est 1. Il n'y a pas d'unit� en somme.