Forum Programmation.c++ pas de copies !

Posté par  .
Étiquettes : aucune
0
4
août
2005
J'ai développée plusieurs classes. Toutes contiennent des pointeurs vers des objets divers.

Je ne vois pas d'utilité de copier un objet d'une de mes classes. Ce serait même dangereux ou demanderais une réflexion supplémentaire.
Tous les échanges se faisant par référence ou pointeur, j'estime pouvoir m'en passer.

Donc, je voudrais interdire toute copie de mes objets.
Je voudrais donc me débarrasser :
- des constructeurs de copie par défaut.
- des opérateurs d'affectation par défaut.
Ainsi, je m'assure que je contrôle mes données et qu'aucune copie n'est réalisée sans que je m'en rende compte.


Pour cela, je pensais ajouter un membre constant à toutes mes classes, genre
const int toto = 1;

Que pensez vous :
- de l'idée ?
- de sa mise en oeuvre ?

Merci.

  • # private

    Posté par  . Évalué à 4.

    Pour se débarrasser du constructeur de copie par défaut et de l'opérateur d'affectation par défaut, il suffit de les redéfinir.
    Et pour ne pas qu'on les utilise, les mettre en section "private".
    My2c

    • [^] # Re: private

      Posté par  . Évalué à 1.

      Je note l'idée.

      Mais je trouve ma proposition d'implémentation encore plus simple et radicale.

      Même à l'intérieur d'une classe, les opérateurs ne serait ainsi plus accessible puisque qu'inexistant.

      Elle repose sur ce que je lis ici :
      http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vc(...)
      J'imagine que c'est dans la norme C++.

      • [^] # Re: private

        Posté par  . Évalué à 3.

        Tu peux aussi déclarer les surcharges d'opérateur (en private) mais pas les définir. Ainsi si quelqu'un tente de les utiliser depuis l'intérieur de la classe il se chope une erreur au link (depuis l'extérieur une erreur de compil).

  • # boost

    Posté par  . Évalué à 2.

    hérite de boost::noncopyable et on en parle plus.

  • # Singleton

    Posté par  . Évalué à 1.

    si tu veux qu'un exemplaire utilise un singleton ou une variante pour limiter le nombre d'instances créées

    • [^] # Pas Singleton non.

      Posté par  (site web personnel) . Évalué à 1.

      Et pour pour définir une singleton "structurel" (vérifié à la compilation), il faut déclarer en privé et ne pas définir les opérations à interdire, ou hériter de boost::non_copyable comme déjà signalé.
      (l'autre type d' approche étant celle de ACE ou Loki, "singleton" étant une caractéristique que l'on colle à un type existant (non "structurellement" singleton) pour en définir un nouveau (type) qui sera un singleton)

      De plus, il n'est pas rare de vouloir disposer de _plusieurs_ objets non copiables. Typiquement quand on a une sémantique de référence, on veut rarement avoir la copie. Cela me semble être la situation dans laquelle locnet (l'OP) se trouve. Sa démarche est bonne, il ne connaissait juste pas les deux idiomes consacrés pour les sémantiques interdisant la copie.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.