Discussion :

[camboui]

Je ne m'étais jamais posé la question de savoir combien de place une structure (ou classe) dépourvue d'attribut prenait de place en mémoire. Spontanément j'aurais dit "zéro" si on m'avait posé la question sans prendre le temps de vérifier ou réfléchir.

Ainsi donc les traits, par exemple, ou bien d'autre classes de la STL ne servant qu'à faire du "typage", sont vides et pourtant leur sizeof() est égal à 1.

Code :

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

1
2
3
4
struct rien_du_tout { };
cout << "résultat: " << sizeof(rien_du_tout) << endl;
 
résultat: 1

C'est curieux.
Mais par ailleurs, si sizeof()==0, comment instantier un objet de rien_du_tout ? Comment imaginer le comportement d'un pointeur vers un emplacement en mémoire d'une instance de rien_du_tout ?

Code :

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

1
2
3
4
struct un_peu: rien_du_tout { char c; };
cout << "résultat: " << sizeof(un_peu) << endl;
 
résultat: 1

Bon, soit...

Mais ça m'embête un peu. J'aimerais quand même que sizeof(rien_du_tout)==0.
Prenons par exemple le cas d'un list< vector<int> > ou d'un list< string > où on consomme de la mémoire "en trop" pour rien. En cause std::allocator qui est une classe "vide" (sous Visual en tout cas) mais qui est "instanciée" dans chaque vector, dans chaque string aussi (et dans tous les conteneurs en général). Et pour peu que l'on fasse un alignement en mémoire (c'est le cas par défaut) on perd 4 octets à chaque instance. C'est cher payé pour "rien".

Pour une fois on aimerait bien que std::allocator soit instanciée une bonne fois pour toute dans une variable globale, d'autant plus que les allocators autre que le standard ne sont pas légions. Dans Loki je crois qu'il y a un SmallObjectAllocator, c'est le seul autre que je connaisse.
J'ai aussi déjà posé la question sur le forum afin de savoir si quelqu'un s'était lancé dans l'écriture d'un allocator, ou les régles à respecter pour le faire. Sans beaucoup de succès...

Bref, pourquoi sizeof(rien_du_tout)==1 et non pas 0 ?

[Davidbrcz]

Tu donnes la réponse: justification ici:

http://www.velocityreviews.com/forum...y-1-byte-.html

http://www.research.att.com/~bs/bs_f...l#sizeof-empty

[ram-0000]

Tient, j'avais posé la même question il y a 1 an : Taille des classes, question à 0,01€

[loufoque]

Si tu hérites d'une classe vide, alors ça n'augmente pas la taille sur la plupart des compilateurs.
C'est comme ça que les conteneurs font pour les allocateurs.

Voir aussi boost::compressed_pair.

[camboui]

Merci.
Je me doutais bien que la réponse était "simplement" dans la distinction d'une instance d'une autre (surtout dans un tableau).

Après réflexion, je me demande si l'argumentation n'est pas un peu faible car finalement l'instantiation d'un contenu vide n'a pas beaucoup de sens. Enfin si, elle a du sens, ce qui n'en a pas c'est de lui attribuer de l'espace mémoire. Ainsi sous le simple prétexte que, par impossible, un programmeur chercherait à distinguer une instance vide d'une autre (ça vous arrive souvent, vous ?), allez, hop, un peu de mémoire inutile consommée pour tout le monde.

Je préfèrerais que sizeof(rien_du_tout)==0. Et, le cas échéant, le compilateur pourrait générer un warning (ou même une erreur) lorsque le code cherche à repérer l'espace mémoire que l'instance occuperait.
Je ne verrais donc pas d'inconvénient à ce que le compilateur refuse des écritures comme celles-ci

Code :

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

1
2
std::vector<rien_du_tout> v;
rien_du_tout arr[25];

[Sylvain Togni]

Si sizeof(rien_du_tout)==0, la question que je me poserai c'est quel est l'intérêt de rien_du_tout, puisque ce n'est rien du tout, autan ne rien utiliser du tout ?