Pourquoi pas un weak être construit à partir d'un unique_ptr?

std::weak_ptr ne peut pas être utilisé, sauf si vous le convertir en std::shared_ptr par les moyens de lock(). si le standard a permis ce que vous suggérez, ce qui signifie que vous avez besoin de convertir std::weak pour unique afin de l'utiliser, en violation de l'unicité (ou ré-inventer std::shared_ptr)

Pour illustrer, considérons les deux morceaux de code:

std::shared_ptr<int> shared = std::make_shared<int>(10);
std::weak_ptr<int> weak(shared);

{
*(weak.lock()) = 20; //OK, the temporary shared_ptr will be destroyed but the pointee-integer still has shared  to keep it alive
}

Maintenant avec votre suggestion:

std::unique_ptr<int> unique = std::make_unique<int>(10);
std::weak_ptr<int> weak(unique);

{
*(weak.lock()) = 20; //not OK. the temporary unique_ptr will be destroyed but unique still points at it! 
}

Qui a été dit, vous pouvez suggérer qu'il existe une seule unique_ptr, et vous ne pouvez toujours déréférencement de weak_ptr (sans créer d'autre unique_ptr), alors il n'y a pas de problème. Mais alors quelle est la différence entre unique_ptr et shared_ptr avec une référence? ou d'ailleurs, quelle est la différence entre un régulier unique_ptr et C-pointeurs une utilisation get?

weak_ptr n'est pas pour "général nonowning ressources", il a une très particulier - Le but principal de weak_ptr est de prévenir la circulaire de pointage de shared_ptr qui fera une fuite de mémoire. Autre chose qui doit être fait avec la plaine unique_ptr et shared_ptr.

Un shared_ptr a en fait deux parties:

1. le-pointu pour objet
2. le nombre de références d'objet

Une fois la référence compteur tombe à zéro de l'objet (#1) est supprimé.

Maintenant un weak_ptr doit être en mesure de savoir si un objet existe toujours. Pour ce faire, il doit être en mesure de voir le nombre de références d'objet (#2) si ce n'est pas de zéro, on peut créer un shared_ptr de l'objet (en incrémentant le nombre de références). Si le compteur est à zéro, il sera de retour un vide shared_ptr.

Maintenant prendre en compte lorsque le compteur de référence de l'objet (#2) peuvent être supprimés? Nous devons attendre jusqu'à ce sans shared_ptr OU weak_ptr objet de référence. À cette fin, le compteur de référence de l'objet tient deux comptes de référence, un forte ref et un faible réf. Le compteur de référence de l'objet ne seront supprimés lors de ses deux comptes sont à zéro. Cela signifie qu'une partie de la mémoire peuvent être libérés après toutes les références faibles ont disparu (ce qui implique une caché inconvénient avec make_shared).

tl;dr; weak_ptr dépend d'un faible nombre de références qui fait partie de shared_ptr, il ne peut pas être un weak_ptr sans shared_ptr.

Personne n'a mentionné l'aspect performance du problème, alors permettez-moi de jeter mon 0.02$.

weak_ptr doit en quelque sorte de savoir quand le correspondant shared_ptrs ont tous disparu de la portée et de l'objet pointé a été libéré et détruit. Cela signifie que shared_ptrs doivent communiquer à la destruction à l'égard de chaque weak_ptr pour le même objet, en quelque sorte. Cela a un certain coût – par exemple, un mondial de la table de hachage doit être mis à jour, où weak_ptr obtient l'adresse du (ou nullptr si l'objet est détruit).

Cela implique aussi de verrouillage dans un environnement multi-thread, donc il peut éventuellement être trop lent pour certaines tâches.

Cependant, l'objectif de unique_ptr est de fournir un à coût zéro RAII-style abstraction de la classe. Par conséquent, il ne devrait pas encourir de tout autre coût que celui de deleteing (ou delete[]ing) de l'objet alloué dynamiquement. Le délai imposé par faire un blocage ou autrement gardé table de hachage d'accès, par exemple, peut être comparable au coût de la libération, cependant, qui n'est pas souhaitable dans le cas de unique_ptr.

Il peut être utile de distinguer les raisons de préférer un unique_ptr sur une shared_ptr.

Performance Une raison évidente de calcul en temps et de mémoire. Tel qu'il est actuellement défini, shared_ptr les objets généralement besoin de quelque chose comme une référence-valeur de nombre, qui prend de l'espace et doivent également être activement maintenu. unique_ptr objets ne le sont pas.

Sémantique Avec un unique_ptr, vous en tant que programmeur avoir une assez bonne idée de la pointe-de objet est sur le point d'être détruites lorsque le unique_ptr sont détruits, ou lorsque l'un de ses méthodes de modification est appelée. Et donc, sur grand ou inconnu des bases de code, à l'aide de unique_ptr statiquement véhicule (et impose) quelques informations sur le programme d'exécution du comportement qui pourrait ne pas être évident.

Les commentaires ci-dessus ont généralement mis l'accent sur la performance basée sur des raisons qu'il serait souhaitable pour weak_ptr objets liés à unique_ptr objets. Mais on peut se demander si la sémantique basée sur l'argument est une raison suffisante pour une version future de la STL à l'appui le cas d'utilisation implicite de la question d'origine.