Discussion :

[kochfet]

Salut,

J'ai une classe C11 hérité de la classe mère C1.

Dans ma fonction main je fais appel au constructeur de recopie de la classe C11. Mais le problème que la classe C11 possède un constructeur paramétré et pas un constructeur de recopie. Est il logique?
remarque : C11 possède des attributs de type pointeur.

Merci d'avance.

[Neckara]

Bonjour,

Je présume que tu parles du constructeur par copie :

Code :

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

Foo(const Foo &);

Est il logique?

Cela dépend de la sémantique de ta classe.

Sémantique d'entité :

• Les instances sont toutes "uniques" et "différentes", ex : Homme("Pierre") != Homme("Pierre")
• Pas de constructeur par copie ni d'opérateur de copie mais éventuellement une méthode clone() ;
• La comparaison "inférieur"/"supérieur" n'a pas de sens, ont doit comparer les instances "par rapport à".

Sémantique de valeur :

• Les instances sont "identiques" si elles ont certains champs en communs. ex : NombreComplexe(5,5) == NombreComplexe(5,5);
• La copie a un sens mais l'héritage n'a alors pas de sens
• La comparaison "inférieur"/"supérieur" a un sens.

Mais bon, dès que koala01 verra ce post, il va te pondre un gros pavé pour tout bien t'expliquer
Au pire, tu peux aller faire une recherche avancée sur le forum pour trouver les messages où il parle de sémantique d'entité/valeur.

[imperio]

La FAQ peut aussi t'aider.

Mais bon, dès que koala01 verra ce post, il va te pondre un gros pavé pour tout bien t'expliquer

Tu lui fais une reputation terrible !

[koala01]

Salut,

Salut,

J'ai une classe C11 hérité de la classe mère C1.

Dans ma fonction main je fais appel au constructeur de recopie de la classe C11. Mais le problème que la classe C11 possède un constructeur paramétré et pas un constructeur de recopie. Est il logique?

C'est en effet "logique", dans le sens où, si tu ne définis pas le constructeur de copie, C++ va en fournir un d'office afin de respecter la forme canonique orthodoxe de Coplien.

L'implémentation "naïve" de ce constructeur qui sera implémenté par C++ consiste à copier le contenu "membre à membre", dans l'ordre de leur déclaration.

Autrement dit, si tu as une classe "point" qui prend la forme de

Code :

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

1
2
3
4
5
6
7
8
9
10
class Point{
    public:
    Point() : x_(0),y_(0){}
    Point(int x, int y):x_(x),y_(y){}
    int x() const{return x_;}
    int y() const{return y_;}
private:
    int x_;
    int y_;
}:

le compilateur fournira d'office un constructeur de copie ressemblant à Point(Point const& other) dont l'implémentation copiera other.x_ dans x_ et other.y_ dans y_. La norme garanti même que cela se fera dans cet ordre bien précis, et non y_ en premier

remarque : C11 possède des attributs de type pointeur.

Ca, ca peut potentiellement poser problème, car, si ce sont des pointeurs nus (comprends : que tu n'utilises pas les pointeurs intelligents comme std::shared_ptr ou std::unique_ptr) c'est uniquement l'adresse de l'élément qui sera copiée.

Un pointeur n'est en effet rien d'autre qu'une valeur numérique entière (généralement non signée) qui correspond à l'adresse mémoire à laquelle on pourra trouver l'élément du type indiqué qui nous intéresse. Si tu ne définis pas correctement le constructeur de copie, ce n'est que cette adresse qui sera copiée, alors que ce que tu veux c'est souvent que l'objet pointé soit lui-même copié. On parle de "copie en profondeur".

C'est la raison pour laquelle tu dois définir le constructeur de copie pour ta classe C11. Mais, n'oublies pas la règle des trois grands qui dit que, si tu dois définir une des fonctions que sont le constructeur de copie, l'opérateur d'affectation ou le destructeur, alors, tu devra définir les deux autres aussi

Ceci étant dit, je tiens quand même à attirer ton attention sur un problème tout particulier : la sémantique de tes classes.

Toutes les classes que l'on peut créer peuvent en effet être classées dans deux catégories distinctes: les classes ayant sémantique de valeur et les classe ayant sémantique d'entité.

Une classe ayant sémantique de valeur est, typiquement, une classe dont il peut exister, à un instant T, plusieurs instances présentant exactement les mêmes valeurs en mémoire. C'est le cas de la classe Point que je t'ai présentée plus haut, d'une éventuelle classe couleur, de la classe std::string, fournie par le langage, pour ne donner que quelques exemples.

Ces classes sont typiquement:

• copiables et affectables (la forme canonique orthodoxe de coplien est de stricte application)
• comparables au minimum par égalité : il y a du sens à demander si la couleur couleur1 est égale à la couleur couleur2
• peu enclines à intervenir dans une hiérarchie de classe : il n'est pas possible de les utiliser dans un héritage privé, que ce soit comme classe de base ou comme classe dérivée.

Quant aux classes ayant sémantique d'entité, ce sont des classes dont il ne peut typiquement pas exister plusieurs instances présentant exactement les mêmes valeurs à un instant T pour éviter d'essayer d'appliquer à l'une les modifications qui devraient être appliquées à l'autre.

C'est, typiquement le cas de classes comme CompteBanquaire, Personne, voiture, Maison, Chat et autres, Bref, toutes les classes qui doivent garantir une "unicité référentielle". Parce que tu serais très faché si ton salaire arrivait sur le compte bancaire de ton voisin, ou si la traite de sa mazerati était déduite du tien

Typiquement, ces classes:

• ne sont ni copiables, ni affectables, pour assurer l'unicité référentielle
• ne sont pas comparables "globalement" par égalité, bien qu'il soit tout à fait possible de comparer certaines valeurs qu'elles exposent (le numéro du compte ou son solde).
• sont identifiables de manière unique et non ambiguë: il y a toujours une (ou plusieurs) informations qui te permettent de t'assurer que l'on parle bien de toi et non d'un autre kochfet qui existerait "par ailleurs"
• sont particulièrement adaptée à l'héritage multiple : voiture pourrait hériter de Véhicule, Maison pourrait hériter de Batiment, CompteBancaire pourrait être dérivé en CompteCourant et CompteEpargne.

Si tu veux que C11 hérite de C1, tes deux classes ont, d'office, sémantique d'entité. Il n'y a donc aucun sens à essayer de définir le constructeur de copie, ni l'opérateur d'affectation car ces deux classes ne devraient pas être copiables ni affectables.

Ce qu'il faudrait faire, c'est surtout faire en sorte ce C1 ne soit ni copiable ni affectable. Cela suffira pour t'assurer que toutes les classes dérivées de C1 ne le soient pas non plus .

Si tu peux utiliser les fonctionnalités de C++11, le plus facile est de déclarer les constructeurs de copie et opérateur d'affectation comme étant delete, sous la forme de

Code :

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

1
2
3
4
5
6
class C1{
public:
    C1(C1 const &) = delete;
    C1 & operator=(C1 const &) = delete;
    /* ... */
};

Si tu n'as pas accès aux possibilités de C++11, tu peux faire hériter de manière privée ta classe C1 de boost::noncopyable sous une forme proche de

Code :

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

1
2
3
4
#include <boost/utility.hpp>
class C1 : private boost::noncopyable{
    /* ... */
};

Si tu ne disposes d'aucune de ces possibilités, tu peux utiliser la méthode "à l'ancienne" en désespoir de cause : déclarer sans les définir le constructeur de copie et l'opérateur d'affectation de ta classe C1 dans l'accessibilité privée

Code :

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

1
2
3
4
5
6
class C1{
    /* ... */
private:
    C1(C1 const &); // !!! on n'en donne pas d'implémentation !!!
    C1 & operator=(C1 const &);// !!! on n'en donne pas d'implémentation !!!
};

De cette manière, si tu essayes de faire une copie ou une affectation des classes dérivées, le compilateur se plaindra que "C1(C1 const &) est privé dans ce contexte" et, si tu essayes de faire une copie de C1, la compilation passera, mais c'est l'éditeur de liens qui se plaindra de ne pas trouver le symbole correspondant au constructeur de copie (ou à l'opérateur d'affectation).

Bref, dans tous les cas, tu seras "bloqué" avant l'exécution et tu éviteras donc de te retrouver avec deux instances totalement identiques d'un objet identifié de manière unique et non ambiguë, car cela serait source d'énormément de problèmes

La FAQ peut aussi t'aider.



Tu lui fais une reputation terrible !

Ouaip, mais bon, il me connaît C'est pas pour rien que je me suis retrouvé bombardé "auteur édité", car une conception juste mon principal cheval de bataille sur ce forum

En plus, il n'avait pas tord, hein?

[Neckara]

};[/CODE]Si tu ne disposes d'aucune de ces possibilités, tu peux utiliser la méthode "à l'ancienne" en désespoir de cause : déclarer sans les définir le constructeur de copie et l'opérateur d'affectation de ta classe C1 dans l'accessibilité privée

Code :

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

1
2
3
4
5
6
class C1{
    /* ... */
private:
    C1(C1 const &); // !!! on n'en donne pas d'implémentation !!!
    C1 & operator=(C1 const &);// !!! on n'en donne pas d'implémentation !!!
};

EN C++11 (loué soit-il), tu peux aussi faire :

Code :

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

1
2
3
4
5
6
class C1{
    /* ... */
private:
    C1(C1 const &) = delete;
    C1 & operator=(C1 const &) = delete;
};

A noter aussi qu'en C++11, tu peux faire :

Code :

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

1
2
3
4
class A final
{
        //...
};

Pour interdire les autres classes d'hériter de "A".

[koala01]

EN C++11 (loué soit-il), tu peux aussi faire :

Code :

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

1
2
3
4
5
6
class C1{
    /* ... */
private:
    C1(C1 const &) = delete;
    C1 & operator=(C1 const &) = delete;
};

Heu, je ne veux rien dire, mais ca, c'ést la toute première possibilité que j'ai envisagée . Si si, lis bien ma réponse, je t'assures

Bon, d'accord, toi, tu les as fait passer en privé alors que je les laissais en public. Mais il n'y a aucune obligation à les faire passer en privé

[Neckara]

A en effet, j'ai dû louper un chapitre de ta réponse désolé.

[jblecanard]

Mais bon, dès que koala01 verra ce post, il va te pondre un gros pavé pour tout bien t'expliquer .

Je me suis dit exactement la même chose et du coup j'ai eu la flemme de répondre .

[koala01]

A en effet, j'ai dû louper un chapitre de ta réponse désolé.

Bah, tu es tout excusé

Je me suis dit exactement la même chose et du coup j'ai eu la flemme de répondre .

Et tu n'es surement pas le seul dans le cas

Décidément, je commence à être trop connu et prévisible sur ce forum

[oodini]

A en effet, j'ai dû louper un chapitre de ta réponse désolé.

Dis plutôt que tu as eu la flemme de tout lire.