héritage privé: Quand l'utiliser ?

Version imprimable

13/05/2013, 22h38
Iradrille

héritage privé: Quand l'utiliser ?

hello,

j'aimerai bien comprendre l'héritage privé...

Je post suite à ce message (cf ici)
(ça à pas l'air de marcher, mais je link le post de Kalith, #9).

Oui, probablement un message de grand débutant ^^"

Quand peut-t-on hérité d'une classe "hinéritable" (destructructeur privé) ?
Et quels sont les "gains" / "pertes" face à un héritage classique ?

Oui, question de débutant, m'enfin, il faut bien =)
13/05/2013, 23h54
koala01

Salut,

Allez, un petit tour vers la FAQ.

L'héritage publique et l'héritage privé sont deux choses totalement différentes:

L'héritage publique permet de profiter de ce que l'on appelle la substituabilité, ce qui ouvre la voie à l'utilisation de comportements polymorphique.

L'idée est que l'on peut transmettre un pointeur ou une référence vers un objet de type dérivé partout à toute fonction qui prend un pointeur ou une référence vers un objet du type de base et que les comportements observés seront ceux que l'on attendrait de la part du type dérivé.

L'héritage privé n'a rien à voir avec la substituabilité : tu ne peux absolument pas envisager de transmettre un pointeur ou une référence vers un objet du type dérivé à une fonction qui attend comme argument un pointeur ou une référence vers un objet du type de base.

La raison en est simple : le type de base n'est purement et simplement pas visible depuis l'extérieur (c'est le principe de l'accessibilité privée ;))

L'héritage privé doit être vu comme une relation "EST IMPLEMENTE EN TERMES DE" et permet, essentiellement, de récupérer facilement certaines fonctions propres au type de base (tout en nous autorisant l'accès à toutes les fonction publique du type de base à l'intérieur des fonctions membres du type dérivé).

C'est une relation finalement très proche de la relation de composition, à ceci près qu'elle te permet, en plus, d'accéder aux éventuelles fonctions protégées du type de base.

C'est donc, malgré tout, une relation beaucoup plus forte que la "simple" composition, et il reste malgré tout chaudement recommandé de préférer la composition à l'héritage privé, à moins bien sur que tu n'aies un besoin impératif de pouvoir accéder aux éventuelles fonctions protégées ;)

Mais dans ce cas, ce qui correspond plus ou moins à hériter des conteneur de la STL, y a t'il une fuite mémoire ?

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
#include <iostream>
 
struct A {
	int *m_a;
 
	A(): m_a(new int[42])
	{ }
 
	~A() {
		delete[] m_a;
	}
 
	virtual  void foo() {
		std::cout << "A\n";
	}
};
 
struct B: private A {
	B(): A()
	{ }
 
	virtual void foo() {
		std::cout << "B\n";
	}
 
};
 
int main() {
	B b;
	b.foo();
 
	return 0;
}

14/05/2013, 00h32
Bousk

Il n'y a aucune fuite mémoire et aucune raison d'y en avoir.
Tu déclares un B, qui a pour typage statique B.
C'est le destructeur de B qui sera appelé, qui appelera automatiquement celui de A, c'est comment fonctionne l'héritage.
Le polymorphisme (la substitualité mentionnée par Koala) est lié au typage dynamique.
14/05/2013, 00h40
Iradrille

Ok!

Je pensais que le destructeur non virtuel posais problème (il y aurait bien une fuite mémoire avec une héritage publique ?)

En tout cas c'est bon à savoir à savoir, merci ! :)
14/05/2013, 01h02
gl
Citation:

Envoyé par Iradrille

Je pensais que le destructeur non virtuel posais problème (il y aurait bien une fuite mémoire avec une héritage publique ?)

Pas avec un tel usage (il n'y de substituabilité ici) que ce soit en héritage privée ou public.

le problème se pose lorsque le type statique et dynamique
Code:

1 2 3 4 5 6 7 8 int main() { A* a = new B; a->foo(); delete a; return 0; }
Construction que te permet l'héritage public. C'est même son principal intérêt : sous-typage et polymorphisme de sous-typage (aka polymorphisme d'inclusion).
Et ne te permet pas l'héritage privé qui est un héritage de réutilisation.

C'est pourquoi les classes où le destructeur n'est pas virtuel ne sont pas des candidats à un héritage public mais peuvent l'être pour un héritage privé (au passage, c'est ce qu'expliquait déjà koala01 dans son post)
14/05/2013, 02h32
Iradrille

Citation:

Envoyé par gl

Construction que te permet l'héritage public. C'est même son principal intérêt : sous-typage et polymorphisme de sous-typage (aka polymorphisme d'inclusion).
Et ne te permet pas l'héritage privé qui est un héritage de réutilisation.

C'est pourquoi les classes où le destructeur n'est pas virtuel ne sont pas des candidats à un héritage public mais peuvent l'être pour un héritage privé (au passage, c'est ce qu'expliquait déjà koala01 dans son post)

Ok, j'avais pas vraiment pas saisi la différence, mais maintenant c'est clair (merci d'avoir exprimé clairement ce que koala01 sous-entendait, ça aide bien à comprendre le truc ;))

En fait, le problème est inverse par rapport à ce que tu crois :aie:

Mais pour te permettre de comprendre cette remarque et, surtout, d'en prendre la pleine mesure, je vais encore une fois devoir me lancer dans un véritable romane (re :aie:)

D'abord, il faut savoir que le destructeur d'une classe est, à quelques points près, tout à fait semblable à n'importe quelle autre fonction.

Les seules différences sont:
que c'est toujours une fonction membre non statique
qu'il ne peut pas prendre d'argument
que c'est l'une des rares fonctions qui ne peut pas avoir de valeur de retour
qu'il est automatiquement appelé lors de la destruction de l'objet
que c'est l'une des quatre fonctions dont le compilateur fournira une version "naive" (publique, non statique, non virtuelle et inline) s'il ne trouve aucune raison de ne pas le faire (les raisons de ne pas le faire étant que nous en ayons donné une déclaration et (c'est préférable) une implémentation :D)
Ensuite, il faut aussi se rappeler de ce qu'est la virtualité d'une fonction.

Lorsque l'on déclare une fonction virtuelle, on demande au compilateur de mettre en place "tout un mécanisme" qui permettra de faire en sorte que si l'on fait appel à cette fonction depuis un pointeur ou une référence sur un objet du type de base alors que l'objet référencé (pointé) est un objet d'un type dérivé, nous observerons le comportement propre au type réel (autrement dit, du type dérivé).

Ce genre de comportement est ce que l'on appelle "le polymorphisme".

De cette manière, si la classe B hérite de la classe A sous une forme proche de
Code:

1 2 3 4 5 6 7 8 class A{ public: virtual void print() const{std::cout<< "je suis un A"<<std::endl;} }; class B : public A{ public: /* virtual */ void print() const{std::cout<<"je suis un B"<<std::endl;} };
le code
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 int main(){ B obj; // une instance "normale" de B A* ptrA = &obj; // un pointeur sur un objet "passant pour être" de type A B* ptrB = &obj; // un pointeur sur un objet de type B A& refA = obj; // une référence sur un objet "passant pour être de type A B& refB = obj; // une référence sur un objet de type B obj.print(); ptrA->print(); ptrB->print(); refA.print(); refB.print(); return 0; }
nous donnera à chaque fois la même sortie, à savoir "je suis un B", et ce, grâce au fait que la fonction print a été déclarée virtuelle dans la classe de base (A).

Par contre, si l'on a les classe C et D et que D hérite de C sous une forme proche de
Code:

1 2 3 4 5 6 7 8 9 10 class C{ public: /* ATTENTION : ceci N'EST PAS UNE FONCTION VIRTUELLE */ void print() const{std::cout<<"je suis un C"<<std::endl;} }; class D : public C{ public: /* ATTENTION : ceci N'EST PAS UNE FONCTION VIRTUELLE */ void print() const{std::cout<<"je suis un D"<<std::endl;} };
le meme code (adapté au nouveaux noms de types ;))
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 int main(){ D obj; // une instance "normale" de D C* ptrC = &obj; // un pointeur sur un objet "passant pour être" de type C D* ptrD = &obj; // un pointeur sur un objet de type D C& refC = obj; // une référence sur un objet "passant pour être de type C D& refD = obj; // une référence sur un objet de type D obj.print(); ptrC->print(); ptrD->print(); refC.print(); refD.print(); return 0; }
donnera une sortie tout à fait différente, sous la forme de "je suis un C" pour ptrC et refC et "je suis un D" pour ptrD et refD.

Ce qui se passe dans ce cas là, c'est que l'implémentation propre à la classe D de la fonction print ne fait que "cacher" l'implémentation propre à la classe C de cette fonction.

Du coup, lorsque l'objet "passe pour êre" de type C, c'est le comportement de l'implémentation de C que l'on observe et, lorsque le type réel de l'objet est utilisé, on observe le comportement du type réel.

Et peut etre vas tu commencer à voir où se situe le problème lorsque le destructeur n'est pas virtuel :question:

Allez, je suis bon prince, je vais te laisser le temps d'un :java: pour y réfléchir ;)

Alors, ca y est :question: Tu as trouvé :question:

Humm... Tu n'as pas l'air convaincu :aie:

Bon. Imaginons que nous ayons deux classe, A et B, et que B hérite de A sous la forme de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class A{ public: /* on ne déclare pas le destructeur de A comme étant virtuel * Le compilateur lui donnera une implémentation publique, * non statique et non virtuelle!!! */ }; class B : public A{ public: B(int size):size_(size), tab_(new int(size)){} ~B(){delete [] tab_} private: int size_; int * tab_; }
Que se passerait il, selon toi, si on les utilisait sous une forme proche de
Code:

1 2 3 4 5 6 int main(){ A * temp = new B(15); /* ... */ delete temp ; return 0; }
AAAHHH, je sens que tu commences à comprendre:

Comme temp est un pointeur sur A, c'est le destructeur (dont l'implémentation est fournie par le compilateur dans le cas présent) de A qui sera appelé, et non celui de B.

Du coup, nous nous retrouverons avec un objet qui n'est que partiellement détruit, et donc, avec une belle fuite mémoire selon mon exemple ;)

Pour que ce code fonctionne correctement, il eut fallu que le destructeur de A soit virtuel.

Maintenant, on peut envisager une autre solution.

On peut parfaitement décider de ne pas rendre le destructeur de la classe de base virtuel, mais de le déclarer dans l'accessibilité protégée.

Cela donnerait des classes proches de
Code:

1 2 3 4 5 6 7 class A{ protected: ~A(){} }; class B : public A{ };
Comme le destructeur de A est protégé, la classe B, et surtout, le destructeur de B (qui hérite de A) est parfaitement en droit d'y accéder.

Ce qui fait qu'un code proche de
Code:

1 2 3 4 5 int main(){ B obj; B * ptr = new B; delete ptr; // ca marche aussi bien avec un pointeur } // qu'avec une variable détruite lorsque l'on sort de la portée dans laquelle elle est déclarée
fonctionnera sans problème.

La seule restriction, c'est que les objets "passant pour être" de type A ne pourront plus être détruits par eux-même.

Ainsi, avec ces deux mêmes classe A et B, le code
Code:

1 2 3 4 5 6 7 8 int main(){ A * ptrA = new A; A * ptrB = new B; /* ... */ delete ptrA; delete ptrB; return 0; }
ne compilera pas sous prétexte que "A::~A() est protégé dans ce contexte", aussi bien pour ptrA que pour ptrB.

Evidemment, tu es surement occupé à te demander "mais à quoi ca sert de permettre cela s'il n'est pas possible de détruire l'objet de type A :question:"

Hé bien, la réponse tient dans le fait que C++ est un langage multiparadigme.

Jusqu'à présent, nous avons parlé du paradigme orienté objets uniquement.

Il est donc temps de parler d'un "mix" entre le paradigme orienté objets et le paradigme générique (les template).

De par leur nature, les classes et les structures template sont "peu enclines" à accepter des fonctions virtuelles

La raison en est toute simple:

Une classe template est souvent définie sous la forme de
Code:

1 2 3 4 template <typename T> class A{ /* tout ce qu'il faut };
ce qui fait que le compilateur ne pourra générer le code exécutable correspondant que... quand il saura quelle taille le type T prend en mémoire, c'est à dire: lorsque la classe A sera utilisée avec un type bien précis.

Et il ne pourra générer le code binaire correspondant à chaque fois qu'en fonction du type particulier qui est utilisé.

De plus, pour générer le code binaire correspondant aux différentes fonctions membre de la classe pour un type T particulier, il devra disposer du code source de la fonction.

Oui, mais, voilà, pour que cela puisse marcher (je ne vais pas trop rentrer dans les détails ici :D), il faut que la fonction soit "inline".

Et c'est là que réside tout le problème : le mécanisme mis en place pour assurer la virtualité d'une fonction n'est, décidément, pas compatible avec l'inlining des fonctions (encore une fois, il faudrait trop rentrer dans les détails pour expliquer pourquoi :aie:)

On ne peut donc pas déclarer le destructeur de A comme étant publique et virtuel.

Par contre, on peut effectivement le déclarer comme étant protégé et non virtuel, et nous pourrions donc écrire un code (qui utilise le CRTP) proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 template <typename T> class A{ protected: A(){} // après tout, si on ne peut pas détruire un A de manière directe, // autant ne pas pouvoir le créer non plus :D ~A(){} }; class B : public A<B>{ /* comme le constructeur et le destructeurs sont dans l'accessibilité * protégée, ils reste accessible depuis les fonctions membres * (essentiellement le constructeur et le destructeur) de B ;) */ };
Alors, bien sur, vous me demanderez sans doute quel est l'avantage de travailler de la sorte.

L'avantage est tout simple: la classe A va agir comme une interface "améliorée": nous pourrons définir "tous les comportements relatifs" au "concept" représenté par la classe A et faire en sorte qu'ils soient d'office adapté au type de la classe dérivée, et ce, sans que l'héritage (multiple :question:) n'occasionne forcément des hiérarchies de classes trop importante (pour rappel : bien que A<truc> et A<machin> dispose de fonctions identique, il n'y a strictement aucun lien entre les deux, et ce, meme si machin hérite de truc :D)