Quelle est l'utilité de " enable_shared_from_this`?

J'ai couru à travers enable_shared_from_this lors de la lecture de la Stimuler.Asio exemples et après la lecture de la documentation, je suis encore perdu pour la manière dont cela devrait être correctement utilisé. Quelqu'un peut-il me donner un exemple et/ou explication lors de l'utilisation de cette classe de sens.

InformationsquelleAutor fido | 2009-04-03

boost boost-asio c++tr1

329

Il vous permet d'obtenir une valide shared_ptr instance de this, quand tout ce que vous avez est this. Sans elle, vous n'avez aucun moyen d'obtenir un shared_ptr à this, sauf si vous avez déjà eu un en tant que membre. Cet exemple de la stimuler la documentation pour enable_shared_from_this:
```
class Y: public enable_shared_from_this<Y>
{
public:

    shared_ptr<Y> f()
    {
        return shared_from_this();
    }
}

int main()
{
    shared_ptr<Y> p(new Y);
    shared_ptr<Y> q = p->f();
    assert(p == q);
    assert(!(p < q || q < p)); //p and q must share ownership
}
```
La méthode f() renvoie un valide shared_ptr, même si elle n'avait pas de membre de l'instance. Notez que vous ne pouvez pas simplement faire ceci:
```
class Y: public enable_shared_from_this<Y>
{
public:

    shared_ptr<Y> f()
    {
        return shared_ptr<Y>(this);
    }
}
```
Le pointeur partagé que cette retourné sera différent de comptage de référence de la "bonne", et l'un d'entre eux finissent par perdre et la tenue d'une balançant de référence lorsque l'objet est supprimé.

enable_shared_from_this est devenue une partie de C++ 11. Vous pouvez également l'obtenir à partir de là, ainsi que de boost.
- +1. Le point clé est que le "évident", technique de simplement retourner shared_ptr<Y>(this) est brisé, parce que cette des vents jusqu'à la création de plusieurs shared_ptr objets distincts des comptes de référence. Pour cette raison, vous ne devez créer plus d'un shared_ptr dans le même pointeur brut.
- Il convient de noter que, dans C++11 et plus tard, c'est parfaitement valide pour utiliser un std::shared_ptr constructeur sur un pointeur brut si il hérite de std::enable_shared_from_this. je ne sais pas si du coup de pouce de la sémantique ont été mis à jour à l'appui de cette.
- Avez-vous un devis pour cela? Sur cppreference.com j'ai lu "la Construction d'un std::shared_ptr pour un objet qui est déjà géré par un autre std::shared_ptr ne sera pas consulter l'stockée en interne de référence faible et par conséquent conduit à un comportement indéfini." (en.cppreference.com/w/cpp/memory/enable_shared_from_this)
- Pourquoi ne pouvez-vous pas juste faire shared_ptr<Y> q = p?
- Autant que je sache, vous le pouvez. Je ne reçois pas le cas d'utilisation se fanent
- Vous pouvez, c'est pourquoi cet exemple n'est pas très utile. Il y a certainement des cas d'utilisation pour bien. Quand il n'y a pas q et vous avez besoin d'un p de l'intérieur de la classe.
- oui, vous pouvez le faire parce que p et q sont tous les deux shared_ptr. enable_shared_from_this est nécessaire lorsque vous êtes à l'intérieur de la classe, par exemple dans la méthode f() que j'avais au-dessus. C'est un exemple simplifié, mais il montre que l'essentiel
- vous avez raison, c'est C++17 et plus tard. Certaines implémentations ont suivi le C++16 sémantique avant il a été libéré. Le traitement approprié pour le C++11 pour C++14 devrait être d'utiliser std::make_shared<T>.
InformationsquelleAutor 1800 INFORMATION
181

de Dr Dobbs article sur des pointeurs faibles, je pense que cet exemple est plus facile à comprendre (source: http://drdobbs.com/cpp/184402026):

...code comme celui-ci ne fonctionne pas correctement:
```
int *ip = new int;
shared_ptr<int> sp1(ip);
shared_ptr<int> sp2(ip);
```
Aucun des deux shared_ptr objets connaît les autres, de sorte que les deux vont essayer de libérer la ressource lorsqu'ils sont détruits. Qui conduit généralement à des problèmes.

De même, si un membre de la fonction a besoin d'un shared_ptr objet qui est propriétaire de l'objet auquel il est appelé, il ne peut pas créer un objet à la volée:
```
struct S
{
  shared_ptr<S> dangerous()
  {
     return shared_ptr<S>(this);   //don't do this!
  }
};

int main()
{
   shared_ptr<S> sp1(new S);
   shared_ptr<S> sp2 = sp1->dangerous();
   return 0;
}
```
Ce code a le même problème que l'exemple précédent, bien que sous une forme plus subtile. Lorsqu'il est construit, le shared_ptobjet r sp1 propriétaire de la nouvellement allouée ressources. Le code à l'intérieur de la fonction de membre de S::dangerous ne connais pas cette shared_ptr objet, de sorte que le shared_ptr objet auquel il renvoie est distincte de sp1. La copie de la nouvelle shared_ptr objet de sp2 n'aide pas; quand sp2 est hors de portée, elle va libérer la ressource, et quand sp1 est hors de portée, elle va libérer la ressource.

La façon d'éviter ce problème est d'utiliser le modèle de classe enable_shared_from_this. Le modèle est un modèle de type d'argument, qui est le nom de la classe qui définit la ressource gérée. Cette classe doit, à son tour, être dérivé du public à partir de ce modèle, comme ceci:
```
struct S : enable_shared_from_this<S>
{
  shared_ptr<S> not_dangerous()
  {
    return shared_from_this();
  }
};

int main()
{
   shared_ptr<S> sp1(new S);
   shared_ptr<S> sp2 = sp1->not_dangerous();
   return 0;
}
```
Lorsque vous faites cela, gardez à l'esprit que l'objet sur lequel vous appelez shared_from_this doit être possédé par un shared_ptr objet. Cela ne fonctionne pas:
```
int main()
{
   S *p = new S;
   shared_ptr<S> sp2 = p->not_dangerous();     //don't do this
}
```
- Merci, cela illustre le problème étant résolu de mieux que de le actuellement accepté de répondre.
- +1: Bonne réponse. En aparté, au lieu de shared_ptr<S> sp1(new S); il peut être préférable d'utiliser shared_ptr<S> sp1 = make_shared<S>();, voir par exemple stackoverflow.com/questions/18301511/...
- Je suis sûr que la dernière ligne devrait lire shared_ptr<S> sp2 = p->not_dangerous(); parce que le piège est ici que vous doit créer un shared_ptr la normale avant de vous appeler shared_from_this() la première fois! C'est vraiment facile de se tromper! Avant le C++17 c'est AC pour appeler shared_from_this() avant exactement un shared_ptr a été créé de façon normale: auto sptr = std::make_shared<S>(); ou shared_ptr<S> sptr(new S());. Heureusement, à partir de C++à partir de 17 de le faire va les jeter.
- MAUVAIS Exemple: S* s = new S(); shared_ptr<S> ptr = s->not_dangerous(); <-- Il est permis d'appeler shared_from_this seulement sur un objet partagé, c'est à dire sur un objet géré par std::shared_ptr<T>. Sinon le comportement est indéfini (jusqu'en C++17)std::bad_weak_ptr est lancé (par le shared_ptr constructeur par défaut construit weak_this) (depuis C++17).. Donc, la réalité est qu'il doit être appelé always_dangerous(), parce que vous avez besoin de la connaissance de si elle a déjà été partagé ou pas.
- Bon point. Il aurait été utile si vous avez soumis une demande de modifier à faire que de corriger. Je viens de le faire. L'autre chose utile aurait été à l'affiche de ne pas choisir subjective, sensible au contexte des noms de méthode!
- C'est une très bonne réponse, absolument génial!
InformationsquelleAutor Artashes Aghajanyan
27

Voici mon explication, à partir d'une noix et des boulons de point de vue (en haut de réponse n'a pas de "clic" avec moi). *Notez que ceci est le résultat d'une enquête sur la source de shared_ptr et enable_shared_from_this qui est fourni avec Visual Studio 2012. Peut-être d'autres compilateurs de mettre en œuvre enable_shared_from_this différemment...*

enable_shared_from_this<T> ajoute un privé weak_ptr<T> instance de T qui détient le "un vrai compte de référence " pour l'instance de T.

Ainsi, lorsque vous créez d'abord un shared_ptr<T> sur un nouveau T*, T*'s internes weak est initialisé avec un refcount 1. La nouvelle shared_ptr essentiellement le dos sur cette weak_ptr.

T peut alors, dans ses méthodes, appel shared_from_this pour obtenir une instance de shared_ptr<T> que dos sur le même stockée en interne nombre de références. De cette façon, vous avez toujours un endroit où T*'s réf-comte est stocké plutôt que d'avoir plusieurs shared_ptr instances qui ne connaissent pas les uns les autres, et chacun pense qu'ils sont les shared_ptr qui est en charge de la réf de comptage T et de les supprimer lors de leur ref-compte à rebours atteint zéro.
- C'est exact, et ce qui est vraiment important partie est So, when you first create... parce que c'est un condition (comme vous le dites l'weak n'est pas initialisé jusqu'à ce que vous passer les objets pointeur dans un shared_ptr ctor!) et cette exigence est là où les choses peuvent aller mal si vous n'êtes pas prudent. Si vous créez pas de shared_ptr avant d'appeler shared_from_this vous obtenez UB - de même, si vous créez plus d'un shared_ptr vous obtenez UB trop. Vous avez en quelque sorte assurez-vous de créer un shared_ptr exactement une fois.
- En d'autres termes, l'idée de enable_shared_from_thisest fragile pour commencer, car le point est d'être en mesure d'obtenir un shared_ptr<T> à partir d'un T*, mais en réalité, lorsque vous recevez un pointeur T* t il n'est généralement pas sûr de supposer quoi que ce soit à ce sujet déjà partagé ou non, et faire le mal deviner UB.
- "interne weak est initialisé avec un refcount 1" la faiblesse de la ptr pour T sont non propriétaire de smart ptr à T. Un faible ptr est un propriétaire de smart ref de suffisamment d'informations pour prendre une possession ptr qui est une "copie" de les autres de posséder ptr. Un faible ptr n'a pas de comptage ref. Il a accès à un comptage ref, comme tous les posséder réf.
InformationsquelleAutor mackenir
3

Noter que l'utilisation d'un boost::intrusive_ptr ne souffre pas de ce problème.
C'est souvent un moyen plus pratique d'obtenir autour de cette question.
- Oui, mais enable_shared_from_this vous permet de travailler avec une API qui accepte expressément shared_ptr<>. À mon avis, une telle API est généralement de de Faire le Mal (comme il est préférable de laisser quelque chose de plus élevé dans la pile propre de la mémoire), mais si vous êtes obligé de travailler avec une API, c'est une bonne option.
- Mieux vaut rester dans la norme, comme beaucoup que vous le pouvez.
InformationsquelleAutor blais
2

C'est exactement la même chose en c++11 et plus tard: C'est pour activer la possibilité de retourner this comme un pointeur partagé depuis this vous donne un pointeur brut.

en d'autres termes, il vous permet de transformer un code comme ceci
```
class Node {
public:
    Node* getParent const() {
        if (m_parent) {
            return m_parent;
        } else {
            return this;
        }
    }

private:

    Node * m_parent = nullptr;
};           
```
dans cette:
```
class Node : std::enable_shared_from_this<Node> {
public:
    std::shared_ptr<Node> getParent const() {
        std::shared_ptr<Node> parent = m_parent.lock();
        if (parent) {
            return parent;
        } else {
            return shared_from_this();
        }
    }

private:

    std::weak_ptr<Node> m_parent;
};           
```
- Cela ne fonctionnera que si ces objets sont toujours gérés par un shared_ptr. Vous souhaiterez peut-être modifier l'interface pour s'assurer qu'il est bien le cas.
- Vous avez absolument raison @curiousguy. Cela va sans dire. J'aime aussi typedef-ing tous mes shared_ptr pour améliorer la lisibilité lors de la définition de mon Api publiques. Par exemple, au lieu de std::shared_ptr<Node> getParent const(), je l'aurais fait normalement exposer comme NodePtr getParent const() à la place. Si vous avez absolument besoin d'accéder à l'intérieur pointeur brut (meilleur exemple: gérer une bibliothèque en C), il n'y a std::shared_ptr<T>::get pour que, qui, je déteste les mentionner parce que j'ai ce pointeur brut accesseur utilisé trop de fois pour les mauvaises raisons.
InformationsquelleAutor mchiasson
-3

Une autre façon est d'ajouter un weak_ptr<Y> m_stub membre dans le class Y. Alors écrire:
```
shared_ptr<Y> Y::f()
{
    return m_stub.lock();
}
```
Utile lorsque vous ne pouvez pas modifier la classe dérivant de l' (par exemple, l'extension des autres personnes de la bibliothèque). Ne pas oublier d'initialiser les membres, par exemple par m_stub = shared_ptr<Y>(this), son est valable même pendant un constructeur.

C'est OK si il y a plus de talons comme celui-ci dans la hiérarchie d'héritage, il ne pourra pas empêcher la destruction de l'objet.

Edit: Comme souligné à juste titre par l'utilisateur nobar, le code serait détruire la Y de l'objet lorsque la mission est terminée et les variables temporaires sont détruits. Donc ma réponse est incorrecte.
- Si votre intention est de produire un shared_ptr<> qui ne supprime pas ses pointee, c'est exagéré. Vous pouvez simplement dire return shared_ptr<Y>(this, no_op_deleter); où no_op_deleter est une fonction unaire objet la prise de Y* et de ne rien faire.
- Il semble peu probable que ce travail est une solution. m_stub = shared_ptr<Y>(this) construisent et immédiatement détruire temporaire shared_ptr à partir de ce. Lorsque cette instruction est terminée, this seront supprimées et toutes les références ultérieures sera bancale.
- L'auteur reconnaît que cette réponse est fausse, donc il pourrait probablement juste de le supprimer. Mais il dernier enregistré en 4,5 ans n'est donc pas susceptible de le faire, quelqu'un pourrait-il avec les puissances supérieures supprimer cette hareng rouge?
- si vous regardez à la mise en œuvre de enable_shared_from_this, elle garde une weak_ptr de lui-même (remplie par le ctor), retourné comme un shared_ptr lorsque vous appelez shared_from_this. En d'autres mots, vous êtes en reproduisant ce enable_shared_from_this offre déjà.
InformationsquelleAutor PetrH

Vous devez vous connecter pour publier un commentaire.