Surcharge operateur =

Bonjour à tous,
Comme l'intitulé du thread l'indique je désire surcharger l'opérateur = dans une classe donnée ! Ma question est quand même un peu plus subtile que ce qu'elle en a l'air.
Supposons que j'utilise une classe A qui possède son propre opérateur = et que je crée alors une classe dérivée B. Je désire désormais implémenter un opérateur = pour cette classe B qui appellerait en premier lieu l'opérateur = de la classe A (un peu à la manière de ce que l'on fait généralement dans les constructeurs de classes dérivées). Ma question est alors on ne peut plus simple : est-il possible de rappeler l'opérateur = de la classe mère ou faut-il le recoder dans l'opérateur = de la classe fille ??? En fait, ce qui motive ma question est l'utilisation de QT... Quand je dérive une classe de la librairie, je voudrais pouvoir écrire le plus simplement possible l'opérateur d'affectation de la classe dérivée (sachant que je ne sais pas toujours exactement quels sont tous les membres de la classe mère...). J'espère que j'aurais été assez clair ! Merci pour vos réponses.

Citation:

---

Comme l'intitulé du thread l'indique je désire surcharger l'opérateur +

---

L'intitulé du thread indique plutôt que tu désires surcharger l'opérateur =.

Citation:

---

Supposons que j'utilise une classe A qui possède son propre opérateur = et que je crée alors une classe dérivée B.

---

Est-ce que A::operator= est virtuelle ?

Oui desole c'est bien l'operateur = que je desire surcharger (mais au fond le probleme est le meme avec + ; je modifie quand meme le premier thread). Et non la méthode = de A n'est pas virtuellle.

Code:

---

1 2 3 4 5 6 7 8

B& B::operator =(const B& b) { A::operator =(b);   // ...   return *this; }

---

Merci beaucoup.

Citation:

---

Envoyé par rulianf

Supposons que j'utilise une classe A qui possède son propre opérateur = et que je crée alors une classe dérivée B.

---

Par défaut (*), si l'héritage est public, pas la peine d'aller plus loin, cela t'explosera à la figure. Les hiérarchies polymorphes sont incompatibles avec les copies de valeurs. Problème de sémantiques.

J'hésite entre :
- tu as cru qu'il fallait toujours définir les opérations de recopie parce que la syntaxe le permet (mauvaise supposition ; erreur de débutant)
- le design n'est pas bon (manque d'expérience C++ et/ou de recul sur les besoins réels)
- tu vas avoir besoin de jeter un sérieux coup d'oeil du côté de l'idiome enveloppe-lettre (si tu es dans un des quelques rares cas particuliers où une sémantique de valeur est requise sur une hiérarchie polymorphe)

(*) Sans recourrir à l'idiome enveloppe-lettre ou designs approchants.

Bon, je réponds à M. Luc Hermitte qui m'affuble (de manière plus que péremptoire, mais, je n'en doute pas, à juste titre) de tous les manques d'expérience et erreurs de débutant de la planète. Certes je ne suis pas un programmeur forcené (non la bible du C++ n'est pas mon livre de chevet...) mais plutôt un autodidacte curieux, intéréssé par les apports du C++ depuis quelques années maintenant... voilà, ça c'était pour soulager ma susceptibilité. Maintenant Luc je me permets de te dire exactement quel était mon but.

J'utilise en réalité les classes QThread et QMutex de QT et je souhaitais créer initialement une classe dérivée de la classe QThread de la manière suivante :

Code:

---

1 2 3 4 5

class FSS_Process: public QThread { ... }

---

Seulement mon délire d'inexpérimenté ne s'arrête pas là car après cette création (certainement fâcheuse et signe d'un manque de pratique plus qu'évident) je souhaitais aussi utiliser un vecteur v de QThread et éventuellement avoir accés à une ligne du type (chose très pratique dans le cas de mon design, mais sûrement fort mal pensée !)

Code:

---

1 2

v(i)=...

---

ce qui bien entendu (choix entre : explosion à la figure, mauvaise supposition, erreur de débutant, manque d'experience ou de recul ou même coup d'oeil du côté de l'idiome enveloppe-lettre - très parlant au demeurant) suppose la définition d'un opérateur = dans ma classe FSS_Process, et aussi d'un opérateur = pour la classe QThread, classe dont les membres et la définition me semblaient un peu vague dans la documentation de Trolltech...

D'où mon idée saugrenue de faire directement appel à l'opérateur = de la classe QThread (dont je ne suis pas complètement sûr qu'il existe réellement ou qu'il soit public) dans la définition de l'opérateur = de FSS_Process ... Bien sûr j'ai d'autres alternatives dans mon petit cerveau de modeste bidouilleur, mais je me demandais juste si cette première idée était éventuellement envisageable...

Voilà, de toute manière j'ai résolu mon problème, le programme (sûrement plus que bancal) fait ce que je veux dans des temps raisonnables -> C'est finalement à peu près ce que je voulais cher Luc mais je ne manquerai pas d'aller jeter un oeil du côté de "l'idiome enveloppe-lettre [... utile ...] dans les cas où une sémantique de valeur est requise sur une hiérarchie polymorphe" ! Merci encore pour ta réponse, très motivante et stimulante pour les néophytes dont je fais sûrement parti.

Hum. Pas le prendre personnellement -- d'ailleurs, toutes mes excuses pour mon style. Cette erreur de débutant, nous sommes nombreux à l'avoir faite. Moi le premier.

Mais soit. Supposons que Qthread soit affectable.
Et que tu aies un QVector de Qthread (sans *).
Et que l'on écrive v[i] = unThreadParticulier; (de type ThreadParticulier)
Comment le compilo peut-il savoir que ce qu'il faut stocker c'est un ThreadParticulier et non un QThread ?
Il ne peut pas.

Mais.. Faisons plus simple et retournons à la case sans vecteur, case sur laquelle QVector::operator[]() repose.

Code:

---

QThread t = unThreadParticulier; // (1)

---

Qu'est-ce que cela va donner ?

La réponse est "rien de bon" vu que tu manipules des valeurs. C'est OK dans les langages ne proposant qu'une sémantique de référence, cela ne fera rien de bon en C++ qui supporte par défaut la sémantique de valeur en l'absence de pointeur ou de références. En C++, t ne pourra pas être autre chose qu'un "simple" QThread. Et donc tu perdrais tout ce qui est propre à la classe que tu as dérivée (on parle de "slicing").

Bref, tu serais obligé d'écrire:

Code:

---

Qthread * t = &unThreadParticulier;

---

Ce qui retransposé au QVector te donnera un QVector<QThread*>. Mais surtout, ce qui lève tout besoin de définir l'opérateur d'affectation.

Quant à l'idiome enveloppe-lettre qui permettrait quant même d'écrire sans surprises le code (1), il suppose que la hiérarchie ait prévu le coup dès les classes mères. Je doute que cela soit le cas dans QT, ils l'aurait documenté vu les implications que cela a.

Merci pour beaucoup ta réponse détaillée Luc. Ne t'inquiète pas, je me doutais bien que l'attaque n'était pas personnelle mais c'était juste que je n'avais pas trop apprécié le ton un peu particulier de ta précédente réponse. Mais bon tout va bien maintenant ! Je voudrais juste ajouter une chose : en fait dans mon précédent message je viens de m'apercevoir que j'avais mis (dans le feu de l'action sans doute) vouloir déclarer un vecteur de QThread mais c'est en fait un vecteur v de FSS_Process que je voulais utiliser... Auquel cas le compilo doit, je suppose, être au courant du type et de l'opérateur qu'il va devoir employer pour l'affectation (c'est à dire l'opérateur = de FSS_Process) et donc plus de confusion possible entre classe mère et fille...

Encore désolé.

Dernière précision: attention, je suis loin d'être persuadé que le QVector<FSS_Process> puisse fonctionner correctement. Je ne dis ça, ni pour l'aspect d'opérateur d'affectation qui ne retrouve plus ses petits, ni pour les eventuelles limitations fonctionnelles (je ne trouve pas le bon mot) de FSS_Process (je fais allusion à l'éventuelle impossibilité de disposer d'un constructeur de recopie public et défini)

Le problème, c'est que je ne vois pas un thread se comporter comme une valeur. Ma vision est qu'il s'agit essentiellement d'une entité. (*)
Peut-être une déformation de la notion de Tâches que j'utilise avec ACE (framework portable fortement orienté reseaux et multitâches). Je vois mal comment on pourrait copier des threads, et surtout je ne vois pas ce que cela pourrait bien signifier (quelles implications pour les attributs et état, pour l'"activation" ?). Bref. A priori une sémantique d'entité et donc de référence.

(*) Valeurs => ce qui est important c'est la valeur, l'état est l'élément discriminant (i et j deux entiers représenterons la même chose si leurs valeurs sont égales). Entité => Chaque élément (alloué) est unique et différent des autres. Peu importe l'état qui peut évoluer.


Bon évidemment, si tu pars sur un QVector<FSS_Process*> tu n'auras aucun problème -- ni besoin des deux opérations de recopie.