Problèmes lors de l'écriture d'un constructeur de copie pour un pointeur intelligent

Question

Le code avec lequel je travaille a sa propre implémentation de pointeur intelligent qui effectue un simple comptage de références. Oui, nous ne devrions pas avoir notre propre implémentation. Oui, nous devrions utiliser un boost ou un autre. Ours avec moi.

Je trouve que je voulais écrire du code comme ceci:

... 
CountedPointer<Base> base; 
... 
CountedPointer<Derived> derived; 
... 
base = derived; 

Cependant, le constructeur de copie pour CountedPointer a un prototype comme celui-ci:

CountedPointer(const CountedPointer<T> &other); 

Ainsi, le code ci-dessus ne sera pas compilé depuis il ne peut pas trouver un constructeur approprié (ou un opérateur d'affectation - c'est la même histoire là). J'ai essayé de réécrire le constructeur de copie avec un prototype comme celui-ci:

template<U> 
CountedPointer(const CountedPointer<U> &other); 

Cependant, je frappe le problème que le constructeur de copie doit accéder à un membre privé de l'objet qu'elle copie (par exemple le pointeur brut) et si elle est dans une spécialisation différente de CountedPointer, ils ne sont pas visibles. Alexandrascu évite ce problème dans sa bibliothèque Loki en ayant des fonctions d'accesseur pour le pointeur encapsulé, mais je préférerais ne pas donner un accès direct au pointeur brut si possible.

Y at-il un moyen que je peux écrire cela pour permettre la dérivée à la copie de base, mais ne permet pas l'accès général au pointeur brut?

Mise à jour: J'ai implémenté la réponse acceptée ci-dessous, et cela fonctionne bien. J'ai passé un moment à comprendre pourquoi mon programme se trompait terriblement lorsque je ne fournissais que la version du constructeur de copie, en remplacement de la version originale non-modélisée. Finalement, je me suis rendu compte que le compilateur ne considère pas la version modélisée comme étant un constructeur de copie, et en fournit un par défaut. Celui par défaut copie simplement le contenu sans mettre à jour le compteur, donc je me retrouve avec des pointeurs pendants et des doubles libres. Le même genre de chose s'applique à l'opérateur d'affectation.

Answer 1

Vous ne pouvez pas les rendre amis? Comme:

template<typename T> 
class CountedPointer { 

    // ... 

    template<U> 
    CountedPointer(const CountedPointer<U> &other); 

    template<typename U> friend class CountedPointer; 
}; 

Answer 2

« Alexandrescu évite ce problème dans sa bibliothèque Loki en ayant des fonctions accesseurs pour le pointeur encapsulé, mais je préfère ne pas donner un accès direct au pointeur brut si possible »

Je pense que le coût de l'ajout d'un getter pointeur brut va être beaucoup moins que le coût de la complexité d'essayer de contourner n'ayant pas accès brut. Il n'existe tout simplement pas de mécanisme de langage pour convertir les instances entre deux classes de modèles non apparentées. Pour le compilateur, ils sont deux choses complètement différentes sans relation au moment de l'exécution. C'est la raison pour laquelle une instance de classe template ne peut pas accéder aux autres private.

Vous pouvez envisager de créer une telle relation avec une classe de base pour tous les CountedPointers. Vous devrez peut-être mettre un vide * dans cette classe de base. Ensuite, vous devrez faire toutes les vérifications vous-même (est-ce que T est dérivé de U alors forcez la distribution ... Puis-je implicitement convertir un T en U?, Si donc forcer une conversion .. etc) mais cela peut devenir assez complexe . Voici un début approximatif pour cette approche:

class CountedPointerBase 
{ 
    void* rawPtr; 
}; 

template <class T> 
class CountedPointer : public ConutedPointerBase 
{ 
     T* myRawT = reinterpret_cast<T*>(rawPtr); 

     template<class U> 
     CountedPointer(CountedPointer<U> u) 
     { 
      // Copying a CountedPointer<T> -> CountedPointer<U> 
      if (dynamic_cast<U*>(myRawT) != NULL) 
      { 
       // Safe to copy one rawPtr to another 
      } 
      // check for all other conversions 
     } 
} 

Il peut y avoir beaucoup d'autres complexités à voir si deux types sont compatibles. Peut-être y a-t-il un lissage de modèle Loki/Boost qui peut déterminer deux arguments de type si vous pouviez les convertir l'un à l'autre.

Quoi qu'il en soit, comme vous pouvez le voir, cela peut être une solution beaucoup plus complexe que l'ajout d'un getter.Etre capable d'obtenir le pointeur brut a également d'autres avantages. Vous pouvez passer des pointeurs bruts dans des fonctions de bibliothèque qui n'acceptent que des pointeurs bruts et les utiliser comme temporaires, par exemple. Cela peut être dangereux, je suppose, si quelqu'un dans votre équipe décide de conserver une copie du pointeur brut par opposition au pointeur intelligent. Cette personne devrait probablement être sommairement giflée à la truite.

Answer 3

Vous résoudre le problème si vous avez un CountedPointer (T * autre); constructeur et un opérateur d'affectation similaire.