question d'un entretien

bonjour:
j'ai eu ce matin une question d'entretien. On a demandé ce qu'affichait ce programme.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

void f(); void g();   class Homme{   public: virtual void f1(){ f(); } ~Homme(){ cout<<"~Personn::Trace"<<endl; } }; class Docteur: public Homme{ public: virtual void f2(){g();} ~Docteur(){cout<<"~Docteur::Trace"<<endl;} }; void f(){ cout<<"f::trace"; } void g(){ cout<<"g::trace"; }     int main(){   Docteur docteur; docteur.f1(); docteur.f2();   Homme* homme=new Docteur; delete homme; }

---

bon, jusqu'à delete homme, je sais ce qu'il se passe.
Quand on détruit le pointeur homme, on appelle le destructeur ~Homme, car on détruit un pointeur de type Homme. Mais en détruisant homme, ne détruisons nous pas la place mémoire allouée par new?

quand on quitte le prog, on affiche:
~Docteur::Trace
~Personn::Trace

mais je ne comprends pas pourquoi.
A l'inverse si delete ne détruit que le pointeur, et non la place mémoire, je comprends parfaitement: les destructeurs sont appelés dans le sens inverse.

Mais la question reste: delete ne détruit il pas la place mémoire, donc l'objet Docteur alloué par new.

merci

Je ne suis plus sûr à 100% mais si je ne raconte pas de betise, ton programme comporte un comportement indéterminé. Il faut que le destructeur de ta classe de base soit virtuel.

Sinon c'est du polymorphisme. Tu as un pointeur de type statique Homme mais un objet réel de type Docteur: donc tu vas appeler es fonctions de Docteur pour peu qu'elles soit déclarée virtuelles dans la classe de base, d'où ma remarque ci dessus.

Note aussi que les destructeurs sont appelés dans l'ordre inverse des constructeurs.

Pour les constructeur, c'est d'abord le constructeur de la classe mère puis celui de la classe dérivée.

Pour les destructeurs, c'est l'inverse (dérivée -> base)

J'ai déjà eu ce genre de question... La personne s'attendait à avoir comme réponse ~Docteur::Trace, alors que la bonne réponse est effectivement "comportement indéterminé".

je ne suis pas d'accord avec vous, c'est le destructeur défini sur Homme qui est appelé et donc cela affiche ~Personn::Trace et cela n'est pas indéterminé : à partir du moment ou le destructeur n'est pas virtuel la chose appelée est déterminé statiquement via le type déterminé à la compilation qui est ici Homme

par contre oui c'est mal de ne pas avoir déclaré les destructeurs comme étant virtuels

on peut d'ailleurs se demander pourquoi en C++ les destructeurs ne sont pas implicitement virtuels ;)

Citation:

---

Envoyé par bruno_pages

je ne suis pas d'accord avec vous, c'est le destructeur défini sur Homme qui est appelé et donc cela affiche ~Personn::Trace et cela n'est pas indéterminé : à partir du moment ou le destructeur n'est pas virtuel la chose appelée est déterminé statiquement via le type déterminé à la compilation qui est ici Homme

---

Le comportement indéfini est dans la norme (merci Loic de confirmer, ^^) , mais pas moyen de remettre la main dessus :S. Je cherche, si quelqu'un sait où c'est, merci à lui :)

Citation:

---

on peut d'ailleurs se demander pourquoi en C++ les destructeurs ne sont pas implicitement virtuels ;)

---

Dans le même genre, pourquoi ne pas rendre toutes les fonctions virtuelles par défaut ? Si tu veux ca, il faut aller coder en Java :D

L'approche du C++ est de ne payer que ce dont on a besoin et de ne rien imposer au programmeur.

Un destructeur virtuel n'a de sens que une classe devant servir d'interface pour une hiérarchie de classe dérivée. Je me sentirai mal si j'avais dans chaque classe un destructeur virtuel (donc un vtable) alors que je n'ai rien demandé et que cette classe n'est clairement pas faite pour être héritée ....

Dans la même optique, c'est pour cette raison qu'il ne faut pas hériter publiquement des conteneurs de la STL (pas de destructeurs virtuels)

Citation:

---

Envoyé par Davidbrcz

Le comportement indéfini est dans la norme (merci Loic de confirmer, ^^)

---

vraiment ? pourquoi y aurait-il un comportement différent pour le destructeur et pour les opérations non virtuelles standard ? j'attends aussi la confirmation :D

Citation:

---

Dans le même genre, pourquoi ne pas rendre toutes les fonctions virtuelles par défaut ?

---

dans le cas des destructeurs c'est vraiment aider les codeurs à se tromper, car il n'y a pas de symétrie avec ce qui se passe au niveau construction où là on n'a pas le choix

sinon je pense aussi qu'il aurait été préférable que les opérations soient virtuelles par défaut, et qu'il faille explicitement dire le contraire, mais on n'est peut être pas loin du verre à moitié vide ou à moitié plein ?

Quand je disais que beaucoup de gens s'attendaient à avoir une mauvaise réponse à cette question...

Citation:

---

5.3.5/3 :
In the first alternative (delete object), if the static type of the operand is different from its dynamic type, the static type shall be a base class of the operand’s dynamic type and the static type shall have a virtual destructor or the behavior is undefined. In the second alternative (delete array) if the dynamic type of the object to be deleted differs from its static type, the behavior is undefined.73)

---

Citation:

---

Envoyé par JolyLoic

the static type shall have a virtual destructor or the behavior is undefined

---

:roll: c'est vraiment un choix catastrophique, pour lever l'indétermination il aurait suffit encore une fois qu'un destructeur soit implicitement virtuel ou que la résolution soit liée au type 'statique'

comment peut-on établir explicitement une règle produisant un indécision :cry:

Citation:

---

Envoyé par bruno_pages

:roll: c'est vraiment un choix catastrophique, pour lever l'indétermination il aurait suffit encore une fois qu'un destructeur soit implicitement virtuel ou que la résolution soit liée au type 'statique'

comment peut-on établir explicitement une règle produisant un indécision :cry:

---

Je ne comprends pas ta remarque !

Note qu'un destructeur d'une classe est implicitement virtuel si l'une des classe dont la classe hérite possède un destructeur virtuel.

Je crois que l'idée derrière est que les compilateurs sont autorisés à modifier l'agencement mémoire d'une classe pour gérer la virtualité. Si on détruit une classe dérivée (avec des fonction virtuelles, et donc ce surcoût en mémoire) depuis un pointeur sur la classe de base (qui n'a peut-être pas de fonction virtuelle, et donc une disposition en mémoire autre), ça peut causer des problèmes.

Pour ce qui est de mettre des destructeurs virtuels par défaut, ça aurait un impact sur les perfs... Et pour ce qui est de les mettre virtuels dès lors que la classe est dérivée, ce n'est pas compatible avec la compilation séparée.

Enfin, pour ce qui est du choix non virtuel par défaut pour les fonctions, je dois avouer que j'aime bien. Et je trouve que ce n'est pas uniquement une histoire de moitié vide, moitié plein. Une fonction virtuelle est un signal fort qu'on est en présence d'un point où le comportement peut être modifié. C'est une fonction qui doit être bien mieux conçue que les autres, car elle doit être très claire non pas sur ce qu'elle fait à l'instant t, mais sur toute la gamme de variation qu'on accepte qu'elle puisse prendre sans casser le programme. C'est un coût de conception que je n'ai envie de payer qu'aux rares endroits où il est nécessaire.

Citation:

---

Envoyé par bruno_pages

:roll: c'est vraiment un choix catastrophique, pour lever l'indétermination il aurait suffit encore une fois qu'un destructeur soit implicitement virtuel ou que la résolution soit liée au type 'statique'

---

La raison du comportement indetermine n'est pas particulierement le choix du destructeur appele que l'appel qui suit a un operateur delete. Passer l'argument correct en presence d'heritage multiple est difficile sans vtable.

En réfléchissant, cela me semble normal que l'on ait l'appel des deux destructeurs, car on a crée au début un objet Docteur. Donc une place mémoire a été allouée, donc on doit appeler les deux destructeurs à la fin.


Puisqu'on y ait, j'avais comme question:

est-ce que -> est le seul moyen d'accéder
>>j'ai répondu oui (je n'ai jamais vu un autre moyen pour y accéder)

>>peut-on surcharger des constructeurs
j'ai dit oui,

est-ce que le pointeur this dans une fonction membre constante est un pointeur constant
>>je ne sais pas

est-ce que l'opérateur de portée :: peut-être surchargé:
>>j'ai dit non

est-ce qu'on peut donner des alias a des namespace
>>j'ai répondu non

est-ce qu'il y a un autre moyen d'accéder aux éléments de namespace que ::
>>j'ai répondu non.

Citation:

---

En réfléchissant, cela me semble normal que l'on ait l'appel des deux destructeurs, car on a crée au début un objet Docteur. Donc une place mémoire a été allouée, donc on doit appeler les deux destructeurs à la fin.

---

On appelle deux destructeurs : 1 sur l'objet homme, un sur l'objet docteur. Le problème, c'est que le premier (delete homme) est en réalité un comportement indéterminé, pour les raisons données par Loic.

Et pour en revenir à l'histoire de destructeur virtuel par défaut, je pense qu'une classe ayant une fonction virtuelle, mais un destructeur non virtuel, devrait au moins être un warning de compilation. J'ai du mal à imaginer un cas où ça puisse être utile, et je ne pense pas que passer le destructeur virtuel, puisqu'il y a déjà une vtable, ait un coût notable.

Sinon :

Citation:

---

est-ce que -> est le seul moyen d'accéder
>>j'ai répondu oui (je n'ai jamais vu un autre moyen pour y accéder)

---

(*p).toto() fonctionne aussi.

Citation:

---

>>peut-on surcharger des constructeurs
j'ai dit oui,

---

Oui : surcharge de constructeur avec des signatures différentes.

Citation:

---

est-ce que le pointeur this dans une fonction membre constante est un pointeur constant
>>je ne sais pas

---

Oui : sinon, tu pourrais modifier l'objet.

Citation:

---

est-ce que l'opérateur de portée :: peut-être surchargé:
>>j'ai dit non

---

Il me semble aussi que non.

Citation:

---

est-ce qu'on peut donner des alias a des namespace
>>j'ai répondu non

---

si :

Code:

---

namespace fs=boost::filesystem;

---

Citation:

---

est-ce qu'il y a un autre moyen d'accéder aux éléments de namespace que ::
>>j'ai répondu non.

---

using namespace std; par exemple, mais ça me semble une réponse tordue à la question.

Citation:

---

Envoyé par deubelte

Puisqu'on y ait, j'avais comme question:

---

Pourquoi ne pas demander ce qu'ils attendaient? (Ou bien ce n'est pas oral?)

Moi je ne me sert des questions que comme d'une base pour la discussion.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Pourquoi ne pas demander ce qu'ils attendaient? (Ou bien ce n'est pas oral?)

Moi je ne me sert des questions que comme d'une base pour la discussion.

---

oui parce que si c'est pas ça, c'est un peu idiot comme entretient. Mais ce n'est pas évident pour tous les recruteurs :)

On a m'a posé aussi une question sur la vtable, et a quoi cela servait. (tout était par écrit.)


J'essaye actuellement de voir d'ailleurs quelle est la taille d'une vtable.

Supposons que l'on ait cette hiérarchie:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class A{   private: int o,int b; public: virtual int f1(int o){....}   };   class B: public A{ private: int o1,int o2; public: int f1(int o){...}; };

---

la taille d'un objet B sera sans surprise, non pas 16, mais 20, j'en déduit que le pointeur sur la vtable fait 4 octets.

Par contre, j'ai beau rajouter des fonctions virtuelles, de différents types tenter de modifier la taille de cette vtable, rien à faire, cela reste constant à 4.

Si on avait 1000 fonctions virtuelles, est-ce que cela changerait quelque chose?
Comment modifier cette taille?

la vtable est liée à la classe, sa taille dépend du nombre total d'opérations virtuelles qui existe en prennant en compte celles definie chez elle et celles définie dans les classes mère (sans compter les doublons bien sur).

au niveau des instances il n'y a seulement un pointeur vers cette table

bien évidemment pour un profil d'opération virtuelle donné est associé un index unique qui est le même pour toutes les classes, l'appel dans le cas d'un héritage simple se résume donc à allez lire dans la vtable à cet index pour y trouver l'adresse où il faut aller.

par contre j'avoue que je ne sais pas comment cela se passe vraiment en cas d'héritage multiple, peut être que les vtables sont mises d'une certaine façon bout à bout ?

Sauf erreur, une vtable n'est jamais qu'un tableau, qui sera, de plus partagé par les différentes instances d'une même classe (car l'adresse à laquelle débute une fonction est clairement définie et unique dans un binaire).

Or, un tableau n'est jamais... que l'adresse de son premier élément.

Il est donc "logique" que la taille d'un objet disposant d'une vtable soit supérieure de la taille nécessaire pour représenter un pointeur, et ce, quel que soit le nombre de fonctions virtuelles déclarées.

Enfin, sous réserve que je ne dise pas de bêtise :P

Citation:

---

Or, un tableau n'est jamais... que l'adresse de son premier élément.

---

exact!!

Ce qui m'amène à me poser la question: comment sont calculés les tailles des fonctions.
par exemple, on a deux fonctions:

Code:

---

1 2 3 4

double f3(double o,double c){ return o; }

---

et

Code:

---

1 2 3 4

double f4(double o){ return o; }

---

eh bien, les deux couts renvoient la même chose: 4 octets.:roll:

Code:

---

1 2 3 4 5 6 7 8 9 10

int main(){   double (*o)(double)=&f4; cout<<sizeof(o);   double (*d)(double,double)=&f3; cout<<sizeof(d);   }

---

votre code ne calcule pas la taille du code des fonctions, dans les deux cas vous afficher seulement la taille d'une adresse

comem vous etes en mode 32 bits cela donne ... 32 bits = 4 octets