Est std::unique_ptr<T> requis connaître la définition complète de T?

Adopté à partir de ici.

La plupart des modèles dans la norme C++ de la bibliothèque doivent être instancié avec une complète types. Cependant shared_ptr et unique_ptr sont partielle exceptions. Certains, mais pas tous de leurs membres peut être instancié avec incomplètes types. La motivation pour ce est de soutenir les expressions idiomatiques telles que pimpl à l'aide de pointeurs intelligents, et sans risque d'un comportement indéfini.

Comportement indéfini peut se produire lorsque vous avez un type incomplète et que vous appelez delete sur elle:

class A;
A* a = ...;
delete a;

Ci-dessus est le code légal. Compiler. Votre compilateur peut ou ne peut pas émettre une alerte de code ci-dessus comme ci-dessus. Lorsqu'il s'exécute, les mauvaises choses qui va probablement se produire. Si vous êtes très chanceux, votre programme va planter. Cependant, plus la probabilité d'un résultat, c'est que votre programme en silence à une fuite de mémoire comme ~A() ne sera pas appelé.

À l'aide de auto_ptr<A> dans l'exemple ci-dessus n'aide pas. Vous obtenez toujours le même comportement indéfini comme si vous aviez utilisé un pointeur brut.

Néanmoins, l'utilisation incomplète des classes dans certains endroits est très utile! C'est là que shared_ptr et unique_ptr de l'aide. L'utilisation de l'un de ces pointeurs intelligents permettra de vous sortir avec un type incomplète, sauf lorsqu'il est nécessaire d'avoir un type complètes. Et le plus important, quand il est nécessaire d'avoir un type complètes, vous obtiendrez une erreur de compilation si vous essayez d'utiliser le pointeur intelligent avec un type incomplète à ce point.

Non plus un comportement indéfini:

Si votre code compile, alors vous avez utilisé un type complètes partout où vous en avez besoin.

class A
{
    class impl;
    std::unique_ptr<impl> ptr_;  //ok!

public:
    A();
    ~A();
    //...
};

shared_ptr et unique_ptr exiger un type dans des endroits différents. Les raisons sont obscures, d'avoir à faire avec une dynamique deleter vs statique deleter. Les raisons précises ne sont pas importantes. En fait, dans la plupart de code, il n'est pas vraiment important pour vous de savoir exactement où une complète est requise. Juste le code, et si vous vous trompez, le compilateur va vous le dire.

Toutefois, dans le cas où il est utile pour vous, voici un tableau qui fait état de plusieurs membres de shared_ptr et unique_ptr à l'égard de l'exhaustivité des exigences. Si le membre exige une complète type, puis l'entrée a un "C", sinon l'entrée de la table est remplie avec "je".

Complete type requirements for unique_ptr and shared_ptr

                            unique_ptr       shared_ptr
+------------------------+---------------+---------------+
|          P()           |      I        |      I        |
|  default constructor   |               |               |
+------------------------+---------------+---------------+
|      P(const P&)       |     N/A       |      I        |
|    copy constructor    |               |               |
+------------------------+---------------+---------------+
|         P(P&&)         |      I        |      I        |
|    move constructor    |               |               |
+------------------------+---------------+---------------+
|         ~P()           |      C        |      I        |
|       destructor       |               |               |
+------------------------+---------------+---------------+
|         P(A*)          |      I        |      C        |
+------------------------+---------------+---------------+
|  operator=(const P&)   |     N/A       |      I        |
|    copy assignment     |               |               |
+------------------------+---------------+---------------+
|    operator=(P&&)      |      C        |      I        |
|    move assignment     |               |               |
+------------------------+---------------+---------------+
|        reset()         |      C        |      I        |
+------------------------+---------------+---------------+
|       reset(A*)        |      C        |      C        |
+------------------------+---------------+---------------+

Toutes les opérations nécessitant pointeur conversions doivent types pour les deux unique_ptr et shared_ptr.

La unique_ptr<A>{A*} constructeur peut s'en tirer avec une incomplètes A seulement si le compilateur n'est pas nécessaire pour mettre en place un appel à ~unique_ptr<A>(). Par exemple, si vous mettez le unique_ptr sur le tas, vous pouvez vous en sortir avec un incomplètes A. Plus de détails sur ce point peut être trouvé dans BarryTheHatchet de l' réponse ici.

Ce n'est pas dépendant de l'implémentation. La raison qu'il fonctionne, c'est parce que shared_ptr détermine le bon destructeur de l'appeler au moment de l'exécution - elle ne fait pas partie de la signature de type. Cependant, unique_ptr's destructeur est partie de son type, et il doit être connu au moment de la compilation.

Juste pour être complet:

En-tête: A. h

class B; //forward declaration

class A
{
    std::unique_ptr<B> ptr_;  //ok!  
public:
    A();
    ~A();
    //...
};

Source A.cpp:

class B {  ...  }; //class definition

A::A() { ... }
A::~A() { ... }

La définition de la classe B doit être vu par un constructeur, un destructeur et tout ce qui peut implicitement supprimer B.
(Bien que le constructeur n'apparaît pas dans la liste ci-dessus, dans VS2017 même le constructeur a besoin de la définition de B. Et cela fait sens lorsque l'on considère que dans le cas d'une exception dans le constructeur de la unique_ptr est à nouveau détruit.)

La réponse la plus simple est juste de l'utilisation shared_ptr à la place.