Discussion :

[deubelte]

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

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

[Davidbrcz]

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)

[JolyLoic]

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é".

[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

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

[Davidbrcz]

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

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

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)

[bruno_pages]

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

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 ?

[JolyLoic]

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

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)