question sur l'héritage en c++

**DLOYAS** · 29/12/2014, 15h59

bonjour tout le monde,

qui peut m'expliquer pourquoi le compilateurva génerer une erreur lors de la compilation de ce code :

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
 
class A { ... };
 
// Héritage public
class B : public A { ... };
 
// Héritage protégé
class C : protected A { ... };
 
// Héritage privé
class D : private A { ... };
 
int main() {
  B b; C c; D d;
  A * ptr;
 
  ptr = &B; // OK
  ptr = &C; // Erreur 
  ptr = &D; // Erreur

**JolyLoic** · 29/12/2014, 16h24

Difficile de répondre autre-chose que : "Parce que c'est comme ça que l'héritage fonctionne"... Peut-être pourrais-tu expliquer ce à quoi tu te serais attendu, et pour quelles raisons, afin qu'on voit mieux où est ton problème avec le comportement actuel ?

Sinon, en terme de logique, le fait que la relation d'héritage ne soit pas public fait qu'un utilisateur extérieur de la classe n'a même pas à avoir conscience qu'elle existe, c'est du coup pour un tel utilisateur comme si A et C n'avaient aucun liens entre eux.

Et en résumé :
- Héritage public : Polymorphisme, utilisé 99% du temps
- Héritage privé : Détail d'implémentation, utilisé à la place de la composition quand on doit redéfinir des fonctions virtuelles ou bénéficier de l'empty base class optimisation. Utilisé 1% du temps.
- Héritage protégé : ???. Utilisé le reste du temps

**koala01** · 29/12/2014, 16h32

Envoyé par DLOYAS

bonjour tout le monde,

qui peut m'expliquer pourquoi le compilateurva génerer une erreur lors de la compilation de ce code :

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
 
class A { ... };
 
// Héritage public
class B : public A { ... };
 
// Héritage protégé
class C : protected A { ... };
 
// Héritage privé
class D : private A { ... };
 
int main() {
  B b; C c; D d;
  A * ptr;
 
  ptr = &B; // OK
  ptr = &C; // Erreur 
  ptr = &D; // Erreur

Salut,

En gros, c'est juste un problème d'accessiblité de la partie qui correspond à la classe A au niveau des autres : comme la fonction main n'est pas une fonction membre de tes classes A, B, C et D, elle ne peut accéder qu'à ce qui se trouve dans l'accessibilité publique de ces classes.

Le type A est donc accessible depuis "n'importe où", pour autant que le fichier d'en-tête dans lequel il est défini soit inclus
Ca fonctionne pour B parce que la partie qui correspond à A est publique dans B, ce qui fait que "n'importe qui" peut y accéder
Dans la classe D, tu indiques que la partie qui correspond à A est placée dans l'accessibilité privée. Cela implique que seules les fonctions membres de D pourront accéder à ce qui se trouve dans A (et encore, pas à tout )
Enfin, dans la classe C, tu indiques que la partie qui correspond à A est placée dans l'accessibilité protégée. Cela implique que seules les fonctions membres de C et les fonctions membres des classes éventuellement dérivées de C pourront accéder à ce qui se trouve dans A (et encore, pas à tout).

Notes que, lorsque l'on envisage l'héritage pour profiter du polymorphisme "classique" (celui dont on parle par défaut qui s'appelle l'héritage par inclusion), il n'y a que l'héritage public qui soit concerné.

L'héritage privé n'est pas une relation "EST-UN" comme on décrit souvent l'héritage à visée polymorphique, mais un relation "EST-IMPLEMETE-EN-TERMES-DE" à laquelle nous aurons souvent intérêt de préférer une simple agrégation (donc pas d'héritage).

Enfin, le langage permet l'héritage protégé, mais je n'ai encore trouvé aucune notion conceptuelle qui le rendrait nécessaire. Et je n'ai pas encore trouvé de raison de l'utiliser

**DLOYAS** · 29/12/2014, 16h38

je ne veux pas trop abuser de votre gentillesse,mais votre réponse m'a changé mes prérequis .
(le fait que la relation d'héritage ne soit pas public fait qu'un utilisateur extérieur de la classe n'a même pas à avoir conscience qu'elle existe)!
pouvez vous m'expliquer svp la difference entre l'heritage public et (privat ou protected) je cherche sur internet mais je ne trouve que des définitions académiques, je voudrai savoir la différence qui existe sur le niveau des droits d'accées aux méthodes de la classe de Base .

et Merci d'avance Monsieur JolyLoic

**koala01** · 29/12/2014, 16h50

L'héritage public, c'est l'héritage que tu utilise généralement lorsque tu as une relation EST-UN (une voiture EST-UN véhicule). Il permet de créer une hiérarchie de classe pour laquelle il est possible de faire passer chaque objet du type "plus dérivé" pour un objet du type "moins dérivé" (on peut transmettre une voiture à une fonction qui attend un véhicule car une voiture est bel et bien un véhicule). On dit qu'il permet la substituabilité, mais le LSP (Liskov Substitution principle ou principe de substitution de Liskov, du nom de la dame qui l'a exprimé) doit impérativement être respecté pour ce genre de relation.

L'héritage privé permet de transformer la classe héritée en "détail d'implémentation" de la classe dérivée. Comme tu l'a si bien fait remarquer, l'utilisateur de la classe dérivée n'a même pas à savoir que la classe hérite de manière privée de la classe de base.

L'héritage protégé : je ne l'ai jamais utilisé

**DLOYAS** · 29/12/2014, 17h15

Merci beaucoup

**white_tentacle** · 29/12/2014, 17h22

Envoyé par koala01

Enfin, le langage permet l'héritage protégé, mais je n'ai encore trouvé aucune notion conceptuelle qui le rendrait nécessaire. Et je n'ai pas encore trouvé de raison de l'utiliser

EST-IMPLÉMENTÉ EN TERME DE + sert de classe de base, on veut que les enfants aient accès aux services fournis par la classe initiale qu’on utilise comme implémentation.

Il me semble en avoir eu « besoin » (tout est relatif, j’aurais certainement pu faire autrement) une fois (de mémoire, j’avais utilisé un héritage protégé pour une politique template, je ne sais plus exactement pour quelle raison l’aggrégation ne me convenait pas), mais je ne retrouve pas le code en question. Ça doit rentrer dans le ε qu’il reste si on suit la description de Loïc

.