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.

[camboui]

J'ai un peu lu la doc MS à propos de l'API windows et du portage 32->64 bits.
Edifiant, un GetFileSize() n'est pas foutu de renvoyer un entier sur 64 bits directement. Ils auraient pu faire l'effort d'adopter le modèle LP64 au lieu LLP64. Enfin, je suppose que ça nous facilite la vie à nous, simples developpeurs

[Mac LAK]

J'ai un peu lu la doc MS à propos de l'API windows et du portage 32->64 bits.
Edifiant, un GetFileSize() n'est pas foutu de renvoyer un entier sur 64 bits directement. Ils auraient pu faire l'effort d'adopter le modèle LP64 au lieu LLP64. Enfin, je suppose que ça nous facilite la vie à nous, simples developpeurs

En quel honneur la fonction GetFileSize() devrait-elle passer à 64 bits, pétant directement toute compatibilité binaire avec le code existant d'ailleurs, sous prétexte d'OS 64 bits ?

Surtout que GetFileSizeEx() existe depuis des lustres, et renvoie une valeur 64 bits...

[Médinoc]

À propos du sizeof: Dans tous les cas, j'éviterais de passer directement le résultat de sizeof à printf(). Et si je veux être portable, je ne passerais pas un size_t non plus, Microsoft ne supportant pas le format C99 pour ces types (il faut mettre %Iu à la place).

Why did the Win64 team choose the LLP64 model?

HS: pourquoi utiliser un reinterpret_cast<> là où un static_cast suffirait?

[screetch]

(HS : pourquoi utiliser un static_cast (qui cache autant l'erreur) plutot qu'un checked_numcast?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
#include <cassert>
 
template< typename TO, typename FROM >
static inline TO checked_cast(FROM from)
{
  TO to = static_cast<TO>(from);
  assert(to == dynamic_cast<TO>(from));
  return to;
}
 
template< typename TO, typename FROM >
static inline TO checked_numcast(FROM from)
{
  TO to = static_cast<TO>(from);
  assert(static_cast<FROM>(to) == from);
  return to;
}
 
int main()
{
  return checked_numcast<unsigned char>(2000);
}

j'ajoute le static/dynamic gratuit mais il est encore plus HS, c'est juste pour moi une extension importante du C++ qui me manque (mais que l'on peut coder)

[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.

[camboui]

En quel honneur la fonction GetFileSize() devrait-elle passer à 64 bits, pétant directement toute compatibilité binaire avec le code existant d'ailleurs, sous prétexte d'OS 64 bits ?

Surtout que GetFileSizeEx() existe depuis des lustres, et renvoie une valeur 64 bits...

Je te retourne la question...

Je me souviens quand Bill Gates disait encore en 91-92 "mais qui donc a besoin de plus de 1Mb de mémoire ?"
En 95 sortait Win95, du 32bits mais pas tout à fait.
En 2001 seulement sortait WinXP, le premier "bon" OS correct de MS (je fait l'impasse sur Win 3.51 et NT4).

Maintenant je réponds à ta question: parce que Bill n'était pas un anticipateur ni un visionnaire, et l'API windows a été mal conçue.
On va en payer les pots cassés pendant longtemps encore.

[Mac LAK]

Maintenant je réponds à ta question: parce que Bill n'était pas un anticipateur ni un visionnaire, et l'API windows a été mal conçue.
On va en payer les pots cassés pendant longtemps encore.

Microsoft assure quelque chose d'assez inconnu sous Linux, à savoir la compatibilité binaire ascendante, sans recompilation, et ceci depuis bientôt 30 ans... J'ai de très très vieux programmes DOS qui continuent de tourner sur XP, par exemple, et j'apprécie beaucoup cette fonctionnalité qui, dans la majorité des cas, n'oblige pas à recompiler et/ou abandonner un programme suite à un changement d'OS... Sauf ceux écrits par (et comme) des gorets bien sûr, qui survivent rarement aux évolutions de Windows. Faut dire aussi qu'à force de taper dans l'API Win32 sans en lire la doc, ni tester les résultats, ni respecter les contraintes d'entrées, il faut bien que ça explose un jour.

Modifier la taille des données de la fonction casserait cette rétrocompatibilité des anciennes applications sans rien apporter de concret.
La base même d'une bonne API, c'est de ne JAMAIS modifier la manière dont fonctionne une méthode de l'API : soit on en fait une nouvelle, étendue, soit on la passe en deprecated. Mais la modifier, c'est le symptôme d'une API extrêmement mal conçue au contraire.

Par rapport aux types définis dans l'API Win32, n'oublie pas qu'il n'y a pas que le C/C++ qui s'interface avec ladite API, d'où nécessité d'abstraire un minimum les types... Mais si les types à taille fixe te sont indispensable, la page Common Data Types te montrera que ces types existent depuis quelques temps déjà, il ne tient qu'à toi de les utiliser. Qu'est-ce que ça peut bien te faire de savoir, par exemple, la taille réelle du type HANDLE ou LPVOID ? Tu n'es de toutes façons pas censé utiliser autre chose que des sizeof pour déterminer ces tailles, et ne pas mettre des tailles en dur ni faire des casts sauvages genre "void*" vers "int"...

Pour le reste :

• Les anciens binaires 32 bits sont de toutes façons déjà limités à 2 Go de taille de données de par leur architecture et/ou d'autres contraintes internes du logiciel.
• Les logiciels 32 bits un minimum bien faits et/ou 64 bits utilisent GetFileSizeEx() et ses consœurs estampillées "Ex", fonctions disponibles depuis plus de DIX ANS.
  Accessoirement, c'est pareil en C/C++, et sous Linux (ftell / ftello).
• On peut donc légitimement se poser la question de savoir si tu n'as pas dormi profondément cette dernière décennie pour en être resté à GetFileSize, sans avoir jamais vu la version étendue...

Merci de ta tentative de troll, toutefois...

Oh, à propos du "Je me souviens quand Bill Gates disait encore en 91-92 "mais qui donc a besoin de plus de 1Mb de mémoire ?"" : je te rappelle qu'à l'époque, les machines à 4 Mo de RAM étaient de vrais monstres de puissance, en général vendus comme "stations graphiques / CAO"... Et les personnes ayant réellement besoin de plus de 1 Mo de RAM étaient effectivement non seulement rarissimes, mais en plus très riches vu le prix de la barrette 1 Mo à cette époque-là...

[screetch]

Microsoft assure quelque chose d'assez inconnu sous Linux, à savoir la compatibilité binaire ascendante

niveau troll...

[Mac LAK]

niveau troll...

Et pourtant... T'es quasi certain de faire tourner un binaire Linux pour kernel 1.6 sur un Linux kernel 2.6 ? Non, au contraire. Linux assure une compatibilité très élevée au niveau des sources, mais impose souvent une recompilation lors des évolutions majeures.

[camboui]

Ceci est invalide:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
#if (sizeof(int)!=4)
...

Comment utilise-t-on les sizeof() dans les directives du preprocesseur ?

[Mac LAK]

Comment utilise-t-on les sizeof() dans les directives du preprocesseur ?

Narf, autant pour moi, c'est une extension spécifique à un de mes compilos, ce truc... J'ai regardé dans le mauvais fichier.

Par défaut, faut faire la même chose, mais à l'exécution, via notamment des assertions du type assert(sizeof(int)==4)...

[camboui]

Bah, j'aimerais faire ça avec le preporcessor. C'est tout de même assez élémentaire.
Le plus surprenant est ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define N sizeof(long)
#if N == 8
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define N 4
#if N == 8
...

Le premier code est refusé, le second accepté

[Mac LAK]

Bah, j'aimerais faire ça avec le preporcessor. C'est tout de même assez élémentaire.

J'ai du code qui fait ça (enfin, en partie du moins), mais ça prends deux pages de tests de macros imbriqués assez infect à lire sans les extensions acceptant le sizeof...

Le plus surprenant est ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define N sizeof(long)
#if N == 8
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
#define N 4
#if N == 8
...

Le premier code est refusé, le second accepté

Ce qui est tout à fait normal, si l'on en croit cette page par exemple : le sizeof est évalué à la compilation et non pas au préprocess. Or, le #if ne sait tester que des expressions numériques, et à ce moment-là ton "N" est une chaîne de caractère valant "sizeof(long)".

[3DArchi]

Salut,
Un petit coup de programmation générique pourrait t'aider

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
template<bool> struct dummy_politique
{
   static void do_it();
};
template<> struct dummy_politique<true>
{
   static void do_it();
};
 
// ...
dummy_politique<sizeof(long)==8>::do_it();

Bien sûr à varier selon les bons plaisirs.