Discussion :

[poukill]

Bonjour à tous,

Après relecture de Effective C++ (histoire de passer le temps dans le train), Scott Meyers mets le doigt sur un point assez délicat : le constructeur par copie généré par le compilo effectue une copie de tous les membres de la classe. Donc en cas d'évolution ultérieure, il n'y a pas besoin de modifier quoique ce soit, le compilo se chargera des membres supplémentaires. Alors que nous, humbles programmeurs, on pourrait oublier de le modifier, ce constructeurs par copie !
J'avoue que cette "facilité" est assez sympathique, et m'amène donc aux questions suivantes :

1. Peut-on laisser le compilo générer le constructeur par copie et ne s'occuper que de l'opérateur d'affectation (avec copy and swap ) ?
2. Dans quels cas il faut absolument le faire à la main ?

Typiquement, pour ce genre de code, j'aurai envie de laisser le compilo gérer. A part certains cas particuliers (variables non copiables genre mutex, etc.), je pense pas que ça pose problème!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
class Widget
{
public:
    virtual void Draw() const = 0;
    // Other functions
 
private:
    boost::shared_ptr<Shape> m_shape_ptr;
    int m_id;
    std::vector<std::string>    m_elements_name;
};

Vous en pensez quoi ?

[nikko34]

ben oui il faut que tu fasses du code seulement si tu as besoin d'un comportement particulier.

Si une classe attribut n'est pas copiable, la tienne en sera pas copiable non plus.

Enfin l'intérêt du C++ quand même c'est qu'il y a beaucoup de choses qu'on est pas obligé de faire ( si on l'utilise de manière basique sans pointeur etc.. )

[Nogane]

Bonjour,
Je pense qu'on devrai toujours se demander si un objet a vraiment besoin d'être copiable. Par exemple widget est un objet polymorphique, il ne faudrait donc mieux pas qu'il soit copiable. En tout cas pas en public. Pour éviter le slicing.

Après, pour les objets qui doivent vraiment être copiable, ben si le constructeur par copie est suffisant alors pourquoi s'embêter? Il faut surtout faire attention aux pointeurs. Doit-on copier le pointeur? ou allouer un nouvel objet? Typiquement, avec un shared_ptr, les deux options sont possible. Si tu veux allouer un nouvel objet, il faudra définir un constructeur par copie.

[poukill]

ben oui il faut que tu fasses du code seulement si tu as besoin d'un comportement particulier.
Enfin l'intérêt du C++ quand même c'est qu'il y a beaucoup de choses qu'on est pas obligé de faire ( si on l'utilise de manière basique sans pointeur etc.. )

Oui c'est sûr. J'avais juste pas mal entendu sur le forum qu'il vallait mieux définir le trio constructeur / copie / affectation pour une classe "complexe". Bon, j'avais peut-être pas tout compris non plus.

Bonjour,
Je pense qu'on devrai toujours se demander si un objet a vraiment besoin d'être copiable. Par exemple widget est un objet polymorphique, il ne faudrait donc mieux pas qu'il soit copiable. En tout cas pas en public. Pour éviter le slicing.

Là, Widget n'était qu'un exemple. Dans une hierarchie polymorphe, on aurait intérêt à passer par Clone() pour renvoyer un type dérivé. Sauf si on gère tout par shared_ptr (comme moi) où on est obligé de renvoyer un type de base...
Le problème de slicing, c'est à la charge du "client". S'il passe par copie au lieu de passer par référence constante, c'est bien dommage...

Après, pour les objets qui doivent vraiment être copiable, ben si le constructeur par copie est suffisant alors pourquoi s'embêter? Il faut surtout faire attention aux pointeurs. Doit-on copier le pointeur? ou allouer un nouvel objet? Typiquement, avec un shared_ptr, les deux options sont possible. Si tu veux allouer un nouvel objet, il faudra définir un constructeur par copie.

On est d'accord., le compilo le fait très bien pour nous dans 99 % des cas. Car on attend le plus souvent shared_ptr qu'il partage la nouvelle donnée...

à vous deux !!

[3DArchi]

Sémantique de copie
Quand dois-je définir un constructeur par copie ?
Quand dois-je définir l'opérateur d'affectation ?
Quand est-ce qu'une classe a une sémantique de d'entité ?

[koala01]

Salut,

En fait, la règle est plutôt: si tu définis un constructeur non trivial (par exemple, parce qu'il fait une allocation dynamique de la mémoire), tu devrais redéfinir le constructeur par copie, l'opérateur d'affectation et le destructeur.

Le tout, modulo les besoins et limitations de ta classe: si ta classe est sensée ne pas être assignable et /ou copiable, tu déclares l'opérateur d'affectation et / ou le constructeur par copie en accessibilité privée, sans les définir (ou tu les déclare delete en C++0x)

[Alp]

Il y a une catégorie de situations où tu DOIS considérer un constructeur de copie fait maison, ou au moins te poser la question : quand tu as en attribut un pointeur.

La question c'est est-ce que tu veux que la copie de ton objet détienne la même adresse (le pointeur lui-même, quoi) ou alors la même instance (ce qui est pointé par le pointeur). Si c'est le premier, pas besoin de faire ton constructeur par copie, mais en gardant à l'esprit que quand l'objet que l'on a copié risque de faire un delete du pointeur dans son destructeur et que ça invaliderait donc le pointeur de ta copie. Si c'est le deuxième, là tu dois considérer le constructeur par copie fait maison. Mais tout ça est bien résumé dans la FAQ.

[poukill]

En effet !
La FAQ reste assez "haut niveau" dessus (en parlant de sémantique), alors que je cherchais des cas concrets en rapport à l'item 5 de Effective C++ de Scott Meyers.
Au final, tout se passe comme je pensais.

Merci à tous.

[screetch]

Je dirai que pour les classes qui contiennent plusieurs champs, pour les rendre copiables je prefere que chaque champ soit copiable individuellement. Si il y a un champ non copiable (un handle, un pointeur) je préfère l'encapsuler dans une classe comme un smart pointeur ou un truc similaire, et ainsi laisser le constructeur de copie original.
Mais ca c'est plus la theorie, je suis sur qu'en pratique je le fais pas souvent...