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.