Considérons la situation suivante, dans laquelle la classe A possède une fonction
membre f (dont nous ne précisons pas les arguments) fournissant un résultat de type t
(quelconque : type de base ou type défini par l’utilisateur, éventuellement type classe) :
class A class B : public A
{ ..... { .....
public : } ;
t f (...) ;
.....
} ;
A a ; // a est du type A
B b ; // b est du type B, dérivé de A
Naturellement, un appel tel que a.f(...) a un sens et il fournit un résultat de type t. Le
fait que B hérite publiquement de A permet alors de donner un sens à un appel tel que :
b.f (...)
La fonction f agira sur b, comme s’il était de type A. Le résultat fourni par f sera
cependant toujours de type t, même, notamment, lorsque le type t est précisément le
type A (le résultat de f pourra toutefois être soumis à d’éventuelles conversions s’il est
affecté à une lvalue).
Cas particulier de l’opérateur d’affectation
Considérons une classe B dérivant d’une classe A.
Si la classe dérivée B n’a pas surdéfini l’opérateur d’affectation, l’affectation de deux
objets de type B se déroule membre à membre, en considérant que la « partie héritée de
A » constitue un membre. Ainsi, les membres propres à B sont traités par l’affectation
prévue pour leur type (par défaut ou surdéfinie, suivant le cas). La partie héritée de A
est traitée par l’affectation prévue dans la classe A.
Si la classe dérivée B a surdéfini l’opérateur =, l’affectation de deux objets de type B
fera nécessairement appel à l’opérateur = défini dans B. Celui de A ne sera pas appelé,
même s’il a été surdéfini. Il faudra donc que l’opérateur = de B prenne en charge
tout ce qui concerne l’affectation d’objets de type B, y compris pour ce qui est des
membres hérités de A (quitte à faire appel à l’opérateur d’affectation de A).
Compatibilité entre objets d’une classe de base et objets
d’une classe dérivée
Considérons :
class A class B : public A
{ ..... { .....
243
membre f (dont nous ne précisons pas les arguments) fournissant un résultat de type t
(quelconque : type de base ou type défini par l’utilisateur, éventuellement type classe) :
class A class B : public A
{ ..... { .....
public : } ;
t f (...) ;
.....
} ;
A a ; // a est du type A
B b ; // b est du type B, dérivé de A
Naturellement, un appel tel que a.f(...) a un sens et il fournit un résultat de type t. Le
fait que B hérite publiquement de A permet alors de donner un sens à un appel tel que :
b.f (...)
La fonction f agira sur b, comme s’il était de type A. Le résultat fourni par f sera
cependant toujours de type t, même, notamment, lorsque le type t est précisément le
type A (le résultat de f pourra toutefois être soumis à d’éventuelles conversions s’il est
affecté à une lvalue).
Cas particulier de l’opérateur d’affectation
Considérons une classe B dérivant d’une classe A.
Si la classe dérivée B n’a pas surdéfini l’opérateur d’affectation, l’affectation de deux
objets de type B se déroule membre à membre, en considérant que la « partie héritée de
A » constitue un membre. Ainsi, les membres propres à B sont traités par l’affectation
prévue pour leur type (par défaut ou surdéfinie, suivant le cas). La partie héritée de A
est traitée par l’affectation prévue dans la classe A.
Si la classe dérivée B a surdéfini l’opérateur =, l’affectation de deux objets de type B
fera nécessairement appel à l’opérateur = défini dans B. Celui de A ne sera pas appelé,
même s’il a été surdéfini. Il faudra donc que l’opérateur = de B prenne en charge
tout ce qui concerne l’affectation d’objets de type B, y compris pour ce qui est des
membres hérités de A (quitte à faire appel à l’opérateur d’affectation de A).
Compatibilité entre objets d’une classe de base et objets
d’une classe dérivée
Considérons :
class A class B : public A
{ ..... { .....
243