"operator =" et dérivation de classe

Bonjour,

J'ai une classe de base qui possède un "operator ="

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class CBase { public: ... CBase & operator = (const CBase & Other); ... private: ... des données membre ... }

---

J'ai une classe qui dérive de cette classe de base et qui possède aussi un "operator ="

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class CDerive : public CBase { public: ... CDerive & operator = (const CDerive & Other); ... private: ... des données membre ... }

---

Mon problème maintenant, comment dans "opérator =" de ma classe derivée appeler "operateur =" de la classe de base

Code:

---

1 2 3 4 5 6 7 8 9 10

CDerive & CDerive::operator = (const CDerive & Other) { // recopie des donnees membre de la classe CDerive "des données membre" = Other."des données membre";   // recopie des donnee membre de la classe de base CBase   // retourne l'instance de la classe return *this; }

---

Une solution serait de déclarer les données membre de CBase en "protected" et d'affecter les variables membre de CBase dans CDerive mais j'aime pas trop.

Si quelqu'un avait une solution "propre", je suis preneur

Je serais tenté de dire que si les variables membres de la classe de base sont en private, la classe dérivée n'a pas à s'en occuper; un objet dérivé n'a pas d'espace mémoire pour les variables membres privées d'un objet de base. D'ailleurs l'opérateur = de la classe dérivée ne vérifie que les variables membres auxquelles il a accès.
On retombe sur nos pattes :D

Je suis tout à fait d'accord avec toi mais comme je surcharge "operator =" de la classe dérivée, "operator =" de la classe de base n'est plus appelé.

Est-ce que ceci fonctionne ?

Code:

---

*static_cast<CBase*>(this) = Other;

---

PS: Au passage, je te conseille quand même de déclarer protected l'opérateur d'affectation et le contructeur de copie de la base...

D'une manière générale, en C++, j'ai tendance à utiliser l'idiome copy-and-swap:
Ainsi, je ne définis pas d'opérateur d'affectation dans la classe de base (j'en déclare un privé, par contre, et je définis un constructeur de copie protégé), et mon swap appelle celui de la classe de base.

Le swap est très intéressant, car même des objets non-copiables et non-assignables peuvent être swappables.

Citation:

---

Envoyé par ram_0000

Je suis tout à fait d'accord avec toi mais comme je surcharge "operator =" de la classe dérivée, "operator =" de la classe de base n'est plus appelé.

---

Et pour moi il n'a pas à être appelé, car tu travailles sur des objets dérivés et non sur des objets de base.

Une méthode un peu crade mais qui marche.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

class CDerive : public CBase { public: CDerive & operator = (const CDerive & Other) { Base *b1=this; const Base *b2=&Other; *b1 = *b2; //appel ici // après tu t'occupe du reste des données propre à CDerive. }   }

---

Généralement, je défini l'opérateur= à partir du constructeur par recopie, et ce dernier bénéficie directement de l'héritage, donc pas de problèmes.

Salut,

Déjà, il faut voir s'il t'est vraiment nécessaire de redéfinir le constructeur de copie et l'opérateur d'assignation...

En effet, ce ne sera nécessaire que si tu travailles avec des pointeurs, pour lesquels tu effectue une allocation dynamique de la mémoire (new) dans le constructeur, et une libération dynamique de celle-ci (delete) dans le destructeur...

Et c'est sans oublier de vérifier s'il est cohérent d'autoriser la copie/affectation de ta classe ;)

Si tu n'as pas recours à l'allocation et à la libération dynamique de mémoire dans le constructeur - parce que tu n'utilise pas de pointeurs, ou que tu as pu déléguer la tache de la gestion dynamique de la mémoire à une autre classe... qui sera sans doute non copiable - le constructeur de copie et l'opérateur d'affectation fournis par le compilateur suffiront bien amplement, et l'implémentation que tu en fera ne sera sans doute pas différente de celle que le compilateur aurait donnée ;)

Et le raisonnement peut tout à fait se suivre si tu utilise des classes ou conteneurs fournis par la S(T)L ;)

Pour tous les autres cas, l'idéal est en effet d'utiliser l'idiome copy-and-swap indiqué par médinoc ;)

Au temps pour moi. Et une implémentation simple du type:

Code:

---

1 2 3 4 5 6 7 8

CDerive& operator = (const CDerive& Other) { CBase::operator=(Other); m_.... = Other.m_....; m_.... = Other.m_....; m_.... = Other.m_....; ..... }

---

Ca ne peut pas fonctionner?

C'est ce qui est déjà fait automatiquement.

Citation:

---

Envoyé par spoutspout

Et une implémentation simple du type:

Code:

---

1 2 3 4 5 6 7 8

CDerive& operator = (const CDerive& Other) { CBase::operator=(Other); m_.... = Other.m_....; m_.... = Other.m_....; m_.... = Other.m_....; ..... }

---

Ca ne peut pas fonctionner?

---

Si, cela marche et c'est ce que je vais utiliser

Merci à tous

Citation:

---

Envoyé par loufoque

C'est ce qui est déjà fait automatiquement.

---

Seulement si ton operator= de la classe de base est virtuel, non? Sinon, il n'a aucune raison d'y passer! (ou alors j'ai loupé un ou deux wagons :D)

Tu n'as besoin de virtualité que si tu utilises des pointeurs vers la classe de base, et que l'opérateur d'affectation est public sur celle-ci.

Ce que je déconseille.

Après vérification, l'operator= de la classe parente n'est pas appelé par l'operator= de la classe dérivée. Ci-joint le fichier qui m'a permis de le vérifier.

Il n'est évidemment pas appelé si tu écris toi-même l'opérateur= de la classe dérivée.
Mais celui généré automatiquement par le compilateur appelle celui de la classe de base, par contre.

OK, on est donc d'accord vu que pour moi il ne faut pas laisser le compilateur définir tout seul l'operator= d'une classe que tu as fait toi-même :D (au cas où l'égalité ne soit pas aussi simple qu'une suite d'"=").
Quelqu'un m'a dit une fois que lorsque l'on fait une classe, il faut bien veiller à implémenter ce qu'il appelait la "forme canonique" de la classe (ça porte peut-être un autre nom):

• Constructeur
• Constructeur par copie
• operator= (+ éventuels autres opérateurs)
• Destructeur virtuel

Est-ce une bonne démarche?

C'est une bonne démarche, mais il y a plusieurs variantes de formes canoniques, selon que la classe est copiable, modifiable, swappable...
Ce que je liste, c'est pour les classes "feuilles"

• Classe non-copiable, non-assignable, mais swappable:
  
  • Constructeur
  • Constructeur par copie: privé, non-défini
  • operator= : privé, non-défini
  • Swap() + spécialisation de std::swap<>
  • Destructeur
• Classe copiable, mais immuable (non-assignable, non-swappable)
  
  • Constructeur
  • Constructeur par copie
  • operator= : privé, non-défini
  • Destructeur
• Classe pleinement copiable, assignable, swappable:
  
  • Constructeur
  • Constructeur par copie
  • operator= : utilise idiome copy-and-swap
  • Swap() + spécialisation de std::swap<>
  • Destructeur

De plus, le destructeur n'a pas forcément à être virtuel.
GotW préconise deux cas pour le destructeur:

• Public et virtuel,
• Protégé et non-virtuel;

Et pour les constructeurs, GotW préconise de les faire protégés pour toutes les classes non-feuilles: Seules les classes feuilles doivent être instanciables.

TOTAl HS : Medinoc, on peut intégrer ca dans la FAQ ?

Je n'y vois aucun inconvénient.