Discussion :

[gbdivers]

Bonjour à tous

J'ai voulu (bêtement) améliorer du code et j'ai donc voulu (bêtement encore) rendre non copiable une classe ayant une sémantique d'entité... Malheureusement, cette classe est utilisée dans un std::vector, qui a besoin de copier les objets.

Existe-t-il une solution simple permettant de faire cela de façon élégante ?

Pour le moment, j'ai utilisé unique_ptr pour pouvoir respecter la sémantique mais j'aimerais savoir si c'est possible de faire cela sans pointeur (je n'ai pas besoin du polymorphisme d'héritage).
J'ai également tenté de mettre la copie en privée et mettre des friend sur les vector et dérivés mais c'est un peu (beaucoup) très lourd.

[Arzar]

Bonjour,

Vu la mention d'unique_ptr je suppose que tu es sur un compilateur qui implémente une bonne partie du C++0x.

Et dans ce cas, une bonne solution est de rendre la classe Déplacable. Avec un D majuscule comme le concept (Movable en anglais) c'est à dire rajouter un constructeur par déplacement et un opérateur d'affectation par déplacement (le move assignment operator).

Je pense d'ailleurs qu'avec l'arrivé du C++0x cette idée de sémantique d'entité devra maintenant inclure le déplacement au même tire que la non-copiabilité. Si on reprend la définition de la faq :

A l'inverse des classes à sémantique de valeur, une classe a une sémantique d'entité si toutes les instances de cette classe sont nécessairement deux à deux distinctes, même si tous les champs de ces instances sont égaux. Elle modélise un concept d'identité : chaque objet représente un individu unique.

Je ne vois pas trop de raison qui empêcherait le déplacement de cet "individu unique".

Note : C'est ce qui a été fait dans la STL avec les iostreams par exemple. On ne pouvait pas précédemment en C++03 mettre de iostreams dans un vector car les stream n'étaient pas copiables. C'est maintenant possible en C++0x car les streams sont déplacables.

[Jean-Marc.Bourguet]

Je ne vois pas trop de raison qui empêcherait le déplacement de cet "individu unique".

Ce qui fait l'individu ce n'est pas le contenu de ses membres, c'est son adresse. Et ça ce n'est pas transférable. Ce qui est transférable, c'est les responsabilités de l'individu.

Pour pouvoir donner les opérations de déplacement à une classe ayant une sémantique d'entité, il faut que la classe ait une responsabilité transférable -- sinon il n'y a rien à déplacer -- et que celle-ci soit suffisamment importante (vraisemblablement ce sera le seul objectif dans la plupart des cas) pour que l'utilisation ne semble pas artificielle. Je ne vois guère -- mais j'ai la curieuse impression d'oublier quelque chose -- que des classes techniques, proches des classes RAII (les responsabilités que celles-ci ont est en effet quelque chose de transférable et cette responsabilité est leur seul objet)

Dans le cas des classes ayant une sémantique de valeur, l'utilisation des opérations de déplacement est purement une optimisation faite pour éviter de perdre un travail fait lors de la création de temporaire.

[koala01]

Salut,

J'aurais presque tendance à dire que tu n'as actuellement pas besoin du polymorphisme d'héritage

Car, de deux choses l'une:

Soit, tu te trouve réellement dans le cas d'une sémantique d'entité, les héritages que tu as définis sont tout à fait "légaux" ( du point de vue du respect de LSP et du point de vue sémantique), et tu voudra, tôt ou tard, profiter du polymorphisme car tes besoins auront évolué. Même si, pour l'instant, tu n'en vois pas l'utilité actuellement, le fait de prévoir dés maintenant une utilisation polymorphe t'évitera bien du souci lorsque son besoin s'en fera sentir par la suite

Soit, tes classes n'ont pas réellement sémantique d'entité, ce qui implique sans doute que tu t'es gouré "quelque part" dans ta décision d'utiliser l'héritage publique (ce qui pourrait être mis en évidence par une application stricte de LSP ou par une réflexion correcte quant à la sémantique des noms que tu as utilisés dans ta hiérarchie de classe sous la forme de "puis-je réellement estimer qu'un XXX (dérivé) EST-UN YYY (base) ") et il n'y a, a priori, que peu de raison de refuser de les copier.

La dernière possibilité que nous pourrions envisager (mais que tu semble avoir écartée) est que tu veuille, effectivement, t'assurer de toujours travailler sur la même instance de tes objets, mais le recours au pointeurs lorsqu'il s'agit de recréer une collection sur base, pourquoi pas, d'une sélection sera alors la seule option envisageable, étant donné que les vector (et autres conteneurs) ne sont pas capable de maintenir des références

Je sais que ce raisonnement a un coté un peu restrictif, mais, à défaut d'en savoir plus sur ton projet, je te conseillerais fortement de suivre ces différentes pistes de réflexion

[Médinoc]

Pour répondre à ta question de base: À ma connaissance, il n'est pas possible de faire une sémantique d'entité sans toucher aux pointeurs ou à un équivalent (index dans un tableau).

[gbdivers]

Merci à tous pour vos réponses.

Je vais rester sur des pointeurs du coup.

J'avais oublié la move semantic (pas encore trop l'habitude de c++0x). Le problème est que ça invalide toutes les références/pointeurs après le move.

Je ne vois pas trop de raison qui empêcherait le déplacement de cet "individu unique".

Ce qui fait l'individu ce n'est pas le contenu de ses membres, c'est son adresse. Et ça ce n'est pas transférable. Ce qui est transférable, c'est les responsabilités de l'individu.

En fait, j'aurais tendance à penser, par défaut, comme Arzar. A part le problème de l'invalidation des références/pointeurs, j'aurais dit qu'une classe avec sémantique d'entité devrait être movable (c'est toujours le même individu, quelque soit sont emplacement dans la mémoire).

@koala01
En fait, le plupart de mes classes (qui concernent ce problème) n'utilisent pas l'héritage mais principalement la composition/association (pas de relation EST-UN).

Je ne sais pas si ça change quelque chose à la question initiale.