supression d'un private...
Le
Stan
Une reflexion à propos de la question posée précédemment sur
l'incidence de la supression d'un private dans un source.
La question d'origine était : Est-ce que le fait de supprimer
un ou plusieurs "private" peut modifier le comportement du programme ?
Dans le cas en question, sans doute pas, mais il est des cas
Par exemple en modifiant le type d"héritage.
La plupart des compilateurs utilisent l'EBO ( Empty Base Optimization ), et
il
s'avère que dans le cas d'un héritage privé d'une classe vide :
class Nutshell { };
, l'EBO peut s'effectuer. Donc, dans la pratique, la taille du code généré
peut varier
selon le type d'héritage ( d'une classe vide ).
En résumé,
class A : private Nutshell
{
private:
int Value;
};
peut avoir une taille différente de :
class A : public Nutshell
{
private:
int Value;
};
Si le code effectue des tests sur la taille de la classe :
if( sizeof( A ) > otherclass ) //
cela peut modifier le comportement du programme à l'execution !
Je sais, c'est tordu ;-)
Et d'ailleurs, mon raisonnement est-il correct ?
--
-Stan
l'incidence de la supression d'un private dans un source.
La question d'origine était : Est-ce que le fait de supprimer
un ou plusieurs "private" peut modifier le comportement du programme ?
Dans le cas en question, sans doute pas, mais il est des cas
Par exemple en modifiant le type d"héritage.
La plupart des compilateurs utilisent l'EBO ( Empty Base Optimization ), et
il
s'avère que dans le cas d'un héritage privé d'une classe vide :
class Nutshell { };
, l'EBO peut s'effectuer. Donc, dans la pratique, la taille du code généré
peut varier
selon le type d'héritage ( d'une classe vide ).
En résumé,
class A : private Nutshell
{
private:
int Value;
};
peut avoir une taille différente de :
class A : public Nutshell
{
private:
int Value;
};
Si le code effectue des tests sur la taille de la classe :
if( sizeof( A ) > otherclass ) //
cela peut modifier le comportement du programme à l'execution !
Je sais, c'est tordu ;-)
Et d'ailleurs, mon raisonnement est-il correct ?
--
-Stan
Poser une question
De toute façon, la taille d'une classe n'est pas garantie par la norme.
Par conséquent, ce genre de code n'est pas portable, ni déterministe (à
par avec une version donnée d'un compilateur sur une plateforme donnée,
à la rigueur).
Donc, il ne faut pas s'étonner si son comportement varie en fonction du
vent et de la pluie, non ?
--
Arnaud
Qu'est-ce qui empêche l'EBO de s'appliquer pour de l'héritage public ?
--
Loïc
Si ma tante en avait...
Me voilà rassuré. Etes-vous prêt à déclarer sur l'honneur que vous
seriez capable de coder un truc comme ça dans un programme sérieux ?
Je ne vois guère que deux int à comparer... Mais ça doit dépendre de
l'humeur du compilo ou plutôt de ceux qui l'ont réalisé. J'avoue n'avoir
probablement jamais eu à utiliser un sizeof global pour une classe. Mais
je vais quand même essayer sur le mien, tenez !
Y a quand même des évidences :
class A{
char x;
};
class B{
int x;
long z;
long v;
long u;
};
if( sizeof( B) > sizeof( A) ) std::cout << "oops" << endl;
La portabilité n'est pas toujours un pré-requis.
Exagérer n'a jamais rendu plus crédible.
--
-Stan
Pour les POD, je crois que la situation est différente.
Et de toutes façons, la norme est une chose, les implémentations
usuelles, une autre.
Pour prendre l'exemple classique, jusqu'à assez récemment, la norme
n'imposait pas que les éléments d'un vector<> soient contigus,
pourtant c'était le cas dans toutes les implémentations.