Discussion :

[koala01]

Salut,

Je me pose actuellement une question qui pourrait parraitre saugrenue.

On nous apprend que quand on crée une classe, il est préférable de définir un constructeur par défaux et un par copie, que sinon le compilateur va placer les siens, et que ca risque de poser problème, soit.

Mais, qu'en est-il des classes abstraites?

En effet, une classe abstraite ne sera JAMAIS instensiée, et, lors de la création de classes dérivées, nous devrons insérer les parametres (éventuellement) nécessaires à la classe abstraite pour pouvoir appeler son constructeur.

La question est donc, en réalité, "si un classe abstraite a besoin de parametres, est-il nécessaire de prévoir un constructeur de copie?" (le constructeur par défaut, la question ne se posant pas tellement finalement)

Merci d'avance à tous ceux qui pourront m'éclairer là dessus

[Eusebe]

On nous apprend que quand on crée une classe, il est préférable de définir un constructeur par défaux et un par copie, que sinon le compilateur va placer les siens, et que ca risque de poser problème, soit.

Tout dépend de ce que ta classe contient... Il peut arriver que le construsteur par défaut créé par le compilo soit tout de même suffisant.

Mais, qu'en est-il des classes abstraites?

En effet, une classe abstraite ne sera JAMAIS instensiée, et, lors de la création de classes dérivées, nous devrons insérer les parametres (éventuellement) nécessaires à la classe abstraite pour pouvoir appeler son constructeur.

En fait, une classe abstraite ne peut pas être instanciée directement. Mais quand tu instancies une classe dérivée de ta classe abstraite, ça commence par "construire" la classe abstraite avant de passer à la partie spécifique de ta classe dérivée. Donc pour une classe abstraite, je pense qu'il faut créer les constructeurs / desctructeurs de la même façon que pour une classe instanciable.

[Laurent Gomila]

Comme pourrait te le dire Luc, hiérarchie de classes (à but polymorphique) et sémantique de valeur vont rarement de paire. Donc à moins que tu n'aies réellement besoin de copier tes instances dérivées, ne cherche pas à définir un constructeur par copie. Si tu n'en n'as pas besoin il vaut même mieux l'interdire (tout comme l'opérateur d'affectation).

[Jean-Marc.Bourguet]

On nous apprend que quand on crée une classe, il est préférable de définir un constructeur par défaux et un par copie, que sinon le compilateur va placer les siens, et que ca risque de poser problème, soit.

Bizarre, la majorité de mes classes déclarent (en privé) mais ne définissent pas de constructeur de copie.

Mais, qu'en est-il des classes abstraites?

Les classes abstraites sont faites pour être utilisées avec du polymorphisme, et le polymorphisme se marie très mal avec une sémantique de valeur, donc avec la copie. Donc sauf rarissimes exceptions les classes abstraites désactivent le constructeur de copie.

Le constructeur par défaut ne pose en général que peu de problème: c'est assez rare que la version du compilateur convienne et qu'en plus il n'y a pas d'autre constructeur (puisque le compilateur ne génère un constructeur par défaut que si aucun autre constructeur n'est déclaré).

[koala01]

En fait, une classe abstraite ne peut pas être instanciée directement. Mais quand tu instancies une classe dérivée de ta classe abstraite, ça commence par "construire" la classe abstraite avant de passer à la partie spécifique de ta classe dérivée. Donc pour une classe abstraite, je pense qu'il faut créer les constructeurs / desctructeurs de la même façon que pour une classe instanciable.

On se comprend bien là dessus, même si je ne l'avais pas explicitement dit, mais le constructeur de la classe abstraite n'a besoin que des paramètres (s'il y en a) qui sont nécessaires à sa construction.

Bizarre, la majorité de mes classes déclarent (en privé) mais ne définissent pas de constructeur de copie.

C'est une solution, mais, dans quelle mesure n'est-ce pas uniquement pour éviter que le compilo ne rajoute de lui-même un constructeur de copie dont tu n'a (sans doute) nullement besoin et qui serait sans doute placé en public?

Les classes abstraites sont faites pour être utilisées avec du polymorphisme, et le polymorphisme se marie très mal avec une sémantique de valeur, donc avec la copie. Donc sauf rarissimes exceptions les classes abstraites désactivent le constructeur de copie.

Ca, par contre, c'est effectivement l'argument qui me faisait déjà pencher vers la désactivation du constructeur de copie

Comme pourrait te le dire Luc, hiérarchie de classes (à but polymorphique) et sémantique de valeur vont rarement de paire. Donc à moins que tu n'aies réellement besoin de copier tes instances dérivées, ne cherche pas à définir un constructeur par copie. Si tu n'en n'as pas besoin il vaut même mieux l'interdire (tout comme l'opérateur d'affectation).

Je suivais effectivement un raisonnement fort similaire, bien que non dit explicitement.

Quelque part vous avez tous trois confirmé ce que je préssentais, même si ma question était quelque peu évasive.

Je vous en remercie grandement, et considère le sujet comme clot (à moins que d'autres n'aient des arguments différents)

[Luc Hermitte]

Comme pourrait te le dire Luc

C'est cool, on peut partir en vacances sans se soucier des forums

Au cas où, pour un des mes plugins-wizards-générateur-de-code pour vim, j'ai distingué quatre cas de figure, les plus "extrêmes" et scolaires :
- classe à sémantique de valeur
- classe d'objet vivant sur la pile, mais à sémantique ni de valeur ni d'entité
- classe à sémantique d'entité dont les instances sont clonables
- classe à sémantique d'entité dont les objets ne sont même pas clonables

A partir de là, j'ai des recettes de cuisine toutes prêtes pour les divers constructeurs, operateur d'affectation, et destructeur requis dans chaque cas de figure.

[koala01]

A vrai dire, ma question rentre dans le cadre d'un projet relativement complexe...

Je me retrouve avec +/- 18 à 20 classes.

L'idée de base, c'est que, dans ces 18 à 20 classes, il y en a 16 à 18 dont le seul but est de servir de membre "à la classe de niveau supérieur", et que chaque classe doit etre en mesure d'accéder "à la classe de niveau supérieur" dont elle est membre, en sachant qu'une classe donnée peut très bien s'avérer etre membre de plusieurs autres classes...

Pour corser le tout, ces 18 à 20 classes doivent disposer de méthodes polymorphiques propres au projet, et la creation de template n'est pas adaptée (ou du moins, pour une grande partie des classes), car le nombre et le type des membres est beaucoup trop variable, déjà rien que si l'on ne regarde que les membres qui seraient d'un type de base (ceux de la STL inclus)

Bref, je me retrouve avec la nécessité de disposer de 2 ou 3 interfaces pour pouvoir en faire dériver toutes les autres classes du projet...

Le tout, en sachant que la partie du projet dont je parle devrait tout juste me permettre de gérer les données, en ce, compris la persistance de celles-ci, de manière la plus portable possible, et avant même d'y intégrer une quelconque interface graphique

Il s'agit donc bel et bien de classes abstraite, vu qu'on est dans le stricte cadre du polymorphisme.

L'astuce, c'est que je gardais en tete la "regle des grand trois": constructeur par défaut, constructeur par copie et opérateur d'assignation sont obligatoires, ainsi que l'avertissement du "si vous ne déclarez pas l'un de ces trois, le compilateur en mettra un générique pour vous, qui risque de ne pas vous convenir".

Je suis bien d'accord avec le fait (c'est la caractéristique première des classes abstraite ) qu'aucune des interfaces ne peut etre instanciée directement, qu'elle ne le seront jamais que grace à l'appel de leur constructeur au sein des constructeurs des classes dérivées.

C'est la raison pour laquelle je me posais sérieusement la question de savoir s'il était judicieux (ou non) d'au moins déclarer le constructeur par copie et l'opérateur d'assignation pour ces interfaces, et, si oui, de l'accessibilité à leur donner.

Accessoirement, comme, normalement, "il n'est pas prévu dans le projet" de pouvoir copier les classes dérivées, le débat pourrait se répercuter sur elles, mais de manière beaucoup moins importante.