constructeur par copie

Bonjour,

J'ai un doute affreux, considérons la classe suivante :

Code:

---

1 2 3 4 5 6 7 8 9 10

class ObjA { public: ObjA(const CString& strvalue) { m_strValue = strvalue; } CString GetText() { return m_strValue; }   protected: CString m_strValue; };

---

PS :si vous n'aimez pas la classe CString vous pouvez remplacer par std:string


maitenant si j'écris :

Code:

---

1 2 3 4 5 6 7 8 9

CString strTmp; ObjA* a = new ObjA( _T("c++ power") ); strTmp = a->GetText();   ObjA aCopy(*a); delete a;   strTmp = aCopy.GetText();

---

est ce valide ou ai-je besoin de déclarer un constructeur par copie ou je ferais un m_strValue = rhs.m_strValue ?

Tu me fiche le doute aussi! :aie:

Je dirais que c'est valide (dans cette situation et pas forcément avec des attributs «pointeurs») en conservant le constructeur de copie par défaut ou en créant un personnalisé

Tu peux le vérifier en changeant CString par une classe de ta conception affichant des messages lors de copie et construction. (Si on printait directement depuis ObjA on changerait le comportement en créant les destructeurs et autre fonctions.)

Non pas besoin, c'est ce que fais le ctor de recopie créer par le compilo.
T'en a besoin que quand la gestion est non triviale.

Comme l'indiquent hiura et Goten, le compilateur va générer un constructeur par copie par default, et dans le cas de ta classe simple, tout va bien se passer.

Mais il faut se méfier comme de la peste du constructeur par copie et de l’opérateur d'assignation par défaut, a un tel point qu'il est recommandé de les 'désactiver' en les déclarant comme privés sans fournir d'implémentation.

En cherchant, rapidement, j'ai trouvé ce lien qui explique le pourquoi de ce conseil. Si tu as toujours des doutes, je peux t'expliquer avec un exemple concret.

Diantre, la qualité de la solution compliant #2 est vraiment mauvaise. Et à plus d'un égard[*]. Je suis impressionné pour un site sur le secure coding.
@xmichelo, on a tout ce qu'il faut, et c'est juste au moins, dans la FAQ.

[*]
- non libération sur l'affectation
- pessimisation avec le test à this dans l'opérateur d'affectation, alors qu'un code exception safe (mais faudrait-il d'abord qu'il soit sans fuite) aurait suffit
- test à this dans le ... constructeur de copy. Mais WTF ??? Sont-ils conscient que c'est impossible ? (à part peut-être en situation d'héritage, mais à quoi bon alors protéger un code qui ne rime à rien et qui a de lui-même toutes les chances de finir en comportement non défini)