sizeof(rien_du_tout) == 1

**camboui** · 20/04/2009, 10h55

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** · 20/04/2009, 11h40

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** · 20/04/2009, 11h44

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

**loufoque** · 20/04/2009, 14h31

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** · 22/04/2009, 11h04

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** · 22/04/2009, 12h26

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 ?

**loufoque** · 22/04/2009, 19h40

Un type vide a beaucoup d'utilités.

**Davidbrcz** · 22/04/2009, 20h46

Envoyé par loufoque

Un type vide a beaucoup d'utilités.

Je n'en doute pas mais je suis curieux de savoir lesquelles.

**loufoque** · 22/04/2009, 21h45

Un exemple a été cité plus haut, les allocateurs.
Il y aussi le policy-based design, la méta-programmation, les tags d'identification, etc.

**Davidbrcz** · 22/04/2009, 22h25

Envoyé par loufoque

Un example a été cité plus haut, les allocateurs.
Il y aussi le policy-based design, la méta-programmation, les tags d'identification, etc.

Pour les allocateurs, je ne vois pas. Je ne maîtrise sans doute pas assez le sujet. Si au passage tu as de la doc dessus, je suis preneur

Les autres me parlent, mais je n'y avait pas pensés naturellement.

**JulienDuSud** · 22/04/2009, 22h58

Envoyé par Davidbrcz

Pour les allocateurs, je ne vois pas. Je ne maîtrise sans doute pas assez le sujet. Si au passage tu as de la doc dessus, je suis preneur

Les autres me parlent, mais je n'y avait pas pensés naturellement.

Imagine un objet de type rien_du_tout.

Tu as un objet, et un objet veut dire de la mémoire allouée, or, pour allouer de la mémoire, il faut une taille d'allocation. Si tu as une taille de 0, tu n'as pas d'allocation (on alloue pas "rien" :p). Or il faut pouvoir retrouver cette variable, donc elle doit avoir une adresse où elle est stockée en mémoire. Pour avoir une adresse, la variable doit être allouée, pour être allouée, elle doit avoir une taille supérieure à 0.

Maintenant, imagine 2 objets de type rien_du_tout.
Si on avait des tailles 0 et donc pas d'allocation, il serait strictement impossible de distinguer ces 2 objets, car en réalité, elles n'existeraient pas réellement.

Pour qu'elles existent, il leur faut une taille d'allocation, d'où le minimum 1.

**Davidbrcz** · 22/04/2009, 23h37

Envoyé par JulienDuSud

Imagine un objet de type rien_du_tout.

Tu as un objet, et un objet veut dire de la mémoire allouée, or, pour allouer de la mémoire, il faut une taille d'allocation. Si tu as une taille de 0, tu n'as pas d'allocation (on alloue pas "rien" :p). Or il faut pouvoir retrouver cette variable, donc elle doit avoir une adresse où elle est stockée en mémoire. Pour avoir une adresse, la variable doit être allouée, pour être allouée, elle doit avoir une taille supérieure à 0.

Maintenant, imagine 2 objets de type rien_du_tout.
Si on avait des tailles 0 et donc pas d'allocation, il serait strictement impossible de distinguer ces 2 objets, car en réalité, elles n'existeraient pas réellement.

Pour qu'elles existent, il leur faut une taille d'allocation, d'où le minimum 1.

Nan, ca ok, j'avais compris mais merci de l'explication mais je suis pas sûr que ca soit ce que loufoque voulait dire ou alors j'ai compris de travers sa phrase.

**Midou45** · 22/04/2009, 23h39

waw sa me rappel s cours de philo ..

Je trouve que c'est logique qu'un objet vide à une taille > 0 , pour la raison d'allocation, mais en tant que débutant en programmation je n'arrive pas à assimiler l'utilité de ces objets vides, je pense qu'ils sont utiles vu cette discussion et la participation des gens.. mais pour moi c'est flou ..

**loufoque** · 23/04/2009, 02h16

Bah std::allocator<T> est un type vide.

**Sylvain Togni** · 23/04/2009, 10h45

Il me semble pas que la norme impose que std::allocator<T> soit un type vide.

Et là est justement l'intérêt d'avoir sizeof(T) > 0 quelque soit le type T, même vide, c'est que les propriétés fondamentales des objets (identité, occupation mémoire, ...) ne dépendent pas du fait qu'ils soient vides ou pas. Et vis-à-vis des templates, notamment, c'est important.

**camboui** · 23/04/2009, 11h09

Envoyé par JulienDuSud

Imagine un objet de type rien_du_tout.

Tu as un objet, et un objet veut dire de la mémoire allouée, or, pour allouer de la mémoire, il faut une taille d'allocation...

Pas d'accord. C'est une vue matérialiste. Un objet c'est d'abord une âme, et ensuite éventuellement un corps

Sérieusement, un objet vide n'a pas besoin de mémoire. Ce n'est conceptuellement pas nécessaire. La preuve, elle ne sera jamais utilisée. Sinon, prouvez-moi qu'un programme compilé va y mettre quelque chose d'utile.

La décision des concepteurs du C++ d'allouer de la mémoire est pratique, sans doute pour simplifier un chouia l'écriture du compilateur. Mais je pense que ce n'était pas fondamentalement nécessaire.

Je ne vois aucun cas pratique et concret où il serait utile de connaître l'adresse en mémoire d'un objet vide afin, éventuellement, de le distinguer d'une autre.
Je repose la question: le faites-vous ?
Si on décidait du jour au lendemain de faire en sorte que les compilos gèrent sizeof(rien_du_tout)==0, faudrait-il revoir et vérifier tous les programmes du monde ?

**camboui** · 23/04/2009, 11h13

Envoyé par Sylvain Togni

Il me semble pas que la norme impose que std::allocator<T> soit un type vide.

Et là est justement l'intérêt d'avoir sizeof(T) > 0 quelque soit le type T, même vide, c'est que les propriétés fondamentales des objets (identité, occupation mémoire, ...) ne dépendent pas du fait qu'ils soient vides ou pas. Et vis-à-vis des templates, notamment, c'est important.

std::allocator<T> est toujours vide, quelque soit T.
Ce n'est pas imposé, c'est un constat dans les implémentations actuelles (au moins sous Visual).

**JulienDuSud** · 23/04/2009, 11h22

Envoyé par camboui

Pas d'accord. C'est une vue matérialiste. Un objet c'est d'abord une âme, et ensuite éventuellement un corps

Sérieusement, un objet vide n'a pas besoin de mémoire. Ce n'est conceptuellement pas nécessaire. La preuve, elle ne sera jamais utilisée. Sinon, prouvez-moi qu'un programme compilé va y mettre quelque chose d'utile.

La décision des concepteurs du C++ d'allouer de la mémoire est pratique, sans doute pour simplifier un chouia l'écriture du compilateur. Mais je pense que ce n'était pas fondamentalement nécessaire.

Je ne vois aucun cas pratique et concret où il serait utile de connaître l'adresse en mémoire d'un objet vide afin, éventuellement, de le distinguer d'une autre.
Je repose la question: le faites-vous ?
Si on décidait du jour au lendemain de faire en sorte que les compilos gèrent sizeof(rien_du_tout)==0, faudrait-il revoir et vérifier tous les programmes du monde ?

La gestion des identités des objet se joue beaucoup plus bas, au niveau CPU et pas au niveau du pré-processeur. Or, pour que le CPU ait connaissance de tes objets, il faut qu'ils existent et qu'il puisse les distinguer les uns des autres, d'où la nécéssite de lui allouer de la mémoire.

Aussi, un type vide reste un type, deux variables dont le type serait différents et qui ne contiendrait pas de données restent 2 types distinctes,

**Davidbrcz** · 23/04/2009, 11h52

Aussi, un type vide reste un type, deux variables dont le type serait différents et qui ne contiendrait pas de données restent 2 types distinctes,

Du point de vue du langage, oui mais conceptuellement, est ce que:

Code :

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

1
2
3
 
class A{};
class B{};

sont différentes l'une de l'autre ?

Je ne pense pas, de là à dire qu'il devrait y avoir une substituabilité entre les deux, il n'y a plus qu'un pas à faire.

**camboui** · 23/04/2009, 11h55

Envoyé par JulienDuSud

La gestion des identités des objet se joue beaucoup plus bas, au niveau CPU et pas au niveau du pré-processeur. Or, pour que le CPU ait connaissance de tes objets, il faut qu'ils existent et qu'il puisse les distinguer les uns des autres, d'où la nécéssite de lui allouer de la mémoire.

Aussi, un type vide reste un type, deux variables dont le type serait différents et qui ne contiendrait pas de données restent 2 types distinctes,

??

Tu veux bien répondre à la question et me dire en quoi le CPU a besoin de connaitre et réserver une zone de mémoire dont il ne fera jamais rien ?