Classes de base dupliquées

Bonjour a tous,

encore et tjs sur le BS 3eme edition ou j avance petit a petit.
Je bloque de temps a autre sur certains points comme par exemple:
p439, §15.2.3 Les classes de base dupliquees

Soit une classe B et C derivant chacune de A. D dérive de B et C.
A<---- B <---- D
A<---- C <----D

A est implémentée comme ceci:

Code:

---

struct Link { Link* next;}

---

La phrase exacte du bouquin est : "Deux objets Link (ie de classe A)
distincts sont utilises pour représenter les liaisons, et les deux listes n
interferent aucunement entre elles".

Voici mes soucis/remarques:

1)Deja je ne comprend pas pourquoi on parle d'objet Link etant donne qu'en
declarant un objet D, je n'ai pas l impression de declarer deux objets A...

De plus, Bjarne insiste en parlant des fonctions virtuelles sur la meme
page:
"Lorsqu'une classe de base commune ne doit pas être représentée par deux objets
distincts, il est possible d'utiliser une classe de base virtuelle".
Il parle bien d'objets pour representer une classe... argh mes neurones s entrechoquent...


2)En fait si je comprend bien avec une conception de la sorte, on cree 2
branches de derivation de Link et pour definir les fonctions membres on va etre obligé
de passer par les sous-classes:
B::A::next ou C::A::next


Qu'en pensez vous?

Salut, et bienvenue sur le forum

Citation:

---

Envoyé par fabthegreat

Bonjour a tous,

encore et tjs sur le BS 3eme edition ou j avance petit a petit.
Je bloque de temps a autre sur certains points comme par exemple:
p439, §15.2.3 Les classes de base dupliquees

Soit une classe B et C derivant chacune de A. D dérive de B et C.
A<---- B <---- D
A<---- C <----D

A est implémentée comme ceci:

Code:

---

struct Link { Link* next;}

---

La phrase exacte du bouquin est : "Deux objets Link (ie de classe A)
distincts sont utilises pour représenter les liaisons, et les deux listes n
interferent aucunement entre elles".

Voici mes soucis/remarques:

1)Deja je ne comprend pas pourquoi on parle d'objet Link etant donne qu'en
declarant un objet D, je n'ai pas l impression de declarer deux objets A...

---

Comprend tu déjà que, si tu déclares un objet de type B, tu déclares, automatiquement aussi un objet de type A, vu que l'héritage est une relation EST-UN, et que donc, par définition, tout objet B... est un ("peut passer pour un")...objet de type A :question:

Si oui, tu comprendra que la logique est strictement pareille pour un objet de type C;)

De plus, même s'il ne sont pas *forcément* accessibles depuis la classe B ou la classe C, tout objet de type B ou de type C contient "intrinsèquement" l'ensemble des membres de la classe A, vu que, par définition, B et C...sont des A...

Intéressons nous maintenant à la classe D.

Si elle n'héritait que de B, tu serais sans doute d'accord pour dire (c'est encore le principe de l'héritage) qu'un objet de type D... est un ("peut passer pour un") objet de type B.

Mais comme B hérite de A, un objet de type D peut passer pour un objet de type B, qui peut lui-même passer pour... un objet de type A....

Au final, la "transitivité" implique que... un objet de type D peut parfaitement passer pour un objet de type A.

Là où cela se complique, c'est quand D hérite non seulement de B (et hérite donc des membres de B et de ceux de A), mais qu'elle hérite aussi de C.

Parce que, si tu observe un D, et que tu ne t'intéresse qu'à ce qu'il a reçu en héritage de B, tu trouve l'ensemble des membres qui sont propres à un B, qui est, entre autres composé... de l'ensemble des membres propre à un A.

Et, bien entendu, la logique reste tout à fait identique si tu ne t'intéresse qu'à ce que ton D a reçu en hértage de C...

Tu as donc les membres de A qui viennent de B et ceux... qui viennent de C, les deux étant clairment distincts :D

C'est un peu comme si tu avais deux A tout à fait séparé: l'un venant de B et l'autre venant de C ;)

Citation:

---

De plus, Bjarne insiste en parlant des fonctions virtuelles sur la meme
page:
"Lorsqu'une classe de base commune ne doit pas être représentée par deux objets
distincts, il est possible d'utiliser une classe de base virtuelle".
Il parle bien d'objets pour representer une classe... argh mes neurones s entrechoquent...

---

Personnellement, ils ont fait trois fois le tour de ma boite crânienne avant que je ne comprenne :D

Mais attention, il ne parle pas de fonctions virtuelles ici, mais d'héritage virtuel ;)

Une classe, c'est un type de donnée, un peu comme tu as les char, les int et les float.

Enfin, reprenons:

Un objet, c'est la représentation "physique" (ou en tout cas en mémoire) d'une instance du type de donnée en question.

Et, si on veut aller plus loin, une variable est une instance du type de donnée clairement identifiée de manière unique parmi l'ensemble des instances de ce type présentes en mémoire

Là où cela se corse, c'est quand on se rend compte qu'avec l'héritage, la classe fille récupère et utilise de facto une instance de la classe mère pour pouvoir fonctionner :P

Citation:

---

2)En fait si je comprend bien avec une conception de la sorte, on cree 2
branches de derivation de Link et pour definir les fonctions membres on va etre obligé
de passer par les sous-classes:
B::A::next ou C::A::next


Qu'en pensez vous?

---

En fait, oui, c'est aussi simple que cela... même si les conséquences sont nombreuses :D

Salut,
C'est indépendant de la sémantique d'héritage : si D hérite de B et C, et ces deux derniers de A, que l'héritage soit public, protégé ou privée, cela revient à construire un objet qui contient les deux branches. C'est un peu comme si en mémoire tu parts de D, tu colles un B et un A, puis tu colle un C et encore un A, et tout ça aggloméré donne l'objet D :
___________
|A|B|A|C|D|
Avec l'héritage virtuel, tu pars d'un D, tu colles un B, tu colles un C et tu ne colles qu'un A :
_________
|A|B|C|D|


La F.A.Q reprend l'explication sur l'héritage virtuel avec des schémas assez clairs.

Effectivement, c est assez bien expliqué.
Merci pour vos reponses qui sont bien claires!

a tres bientot

Pour ajouter des petites remarques après mes remerciements:

en fait je pense que ce qui me manque pour bien comprendre les hiérarchies de classes, c'est la facon dont un objet de classe D est géré en mémoire, si le programme crée des objets des classes de base en mémoire, et c...mais je pense que Bjarne ne va pas tarder à me l'expliquer, enfin j'espere... ;)

Mais bon d'une facon générale je trouve, même si c'est une bible, que ce bouquin n'est pas très clair pour un débutant, et demande de multiples relectures!

a+

Une façon triviale de le voir est de se dire qu'à chaque héritage, tu rajoutes l'espace mémoire de la classe de base autour de l'espace utilisé par la classe dérivée :
A <- B :
A : |A|
B : |A|B|
Quand tu as de l'héritage multiple non virtuel, tu rajoutes autant de case que de classe de base :
A<-B
A<-C
B,C <- D
A : |A|
B : |A|B|
C : |A|C|
D: |A|B|A|C|D|

Avec l'héritage virtuel, les classes héritées virtuellement ne sont rajoutées qu'une fois :
A<- (virtuel) B
A<- (virtuel) C
B,C <- D
A : |A|
B : |A|B|
C : |A|C|
D: |A|B|C|D|