Qual é a utilidade do `enable_shared_from_this`?

Corri enable_shared_from_thisao ler os exemplos do Boost.Asio e depois de ler a documentação, ainda estou perdida pela maneira como isso deve ser usado corretamente. Alguém pode me dar um exemplo e uma explicação de quando usar essa classe faz sentido.

Ele permite que você obtenha uma shared_ptrinstância válida para thisquando tudo o que você tem é this. Sem ele, você não teria nenhuma maneira de obter um shared_ptrpara this, a menos que você já teve um como um membro. Este exemplo da documentação do impulso para 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
}

O método f()retorna um válido shared_ptr, mesmo que não tivesse instância de membro. Observe que você não pode simplesmente fazer isso:

class Y: public enable_shared_from_this<Y>
{
public:

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

O ponteiro compartilhado que isso retornou terá uma contagem de referência diferente da "adequada" e uma delas acabará perdendo e mantendo uma referência pendente quando o objeto for excluído.

enable_shared_from_thistornou-se parte do padrão C ++ 11. Você também pode obtê-lo de lá, bem como do impulso.

do artigo do Dr. Dobbs sobre indicadores fracos, acho que este exemplo é mais fácil de entender (fonte: http://drdobbs.com/cpp/184402026 ):

... código como este não funcionará corretamente:

int *ip = new int;
shared_ptr<int> sp1(ip);
shared_ptr<int> sp2(ip);

Nenhum dos dois shared_ptrobjetos conhece o outro, portanto, ambos tentarão liberar o recurso quando forem destruídos. Isso geralmente leva a problemas.

Da mesma forma, se uma função membro precisar de um shared_ptrobjeto que possua o objeto em que está sendo chamada, ela não poderá simplesmente criar um objeto em tempo real:

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;
}

Este código tem o mesmo problema que o exemplo anterior, embora de uma forma mais sutil. Quando é construído, o shared_ptobjeto r sp1possui o recurso recém-alocado. O código dentro da função de membro S::dangerousnão sabe sobre esse shared_ptrobjeto, portanto, o shared_ptrobjeto que ele retorna é distinto sp1. Copiar o novo shared_ptrobjeto para sp2não ajuda; quando sp2sai do escopo, ele libera o recurso e, quando sp1sai do escopo, libera o recurso novamente.

A maneira de evitar esse problema é usar o modelo de classe enable_shared_from_this. O modelo usa um argumento de tipo de modelo, que é o nome da classe que define o recurso gerenciado. Essa classe, por sua vez, deve ser derivada publicamente do modelo; como isso:

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;
}

Ao fazer isso, lembre-se de que o objeto no qual você chama shared_from_thisdeve pertencer a um shared_ptrobjeto. Isso não vai funcionar:

int main()
{
   S *p = new S;
   shared_ptr<S> sp2 = p->not_dangerous();     // don't do this
}

Aqui está minha explicação, do ponto de vista de porcas e parafusos (a resposta principal não 'clicou' comigo). * Observe que esse é o resultado da investigação da origem do shared_ptr e do enable_shared_from_this fornecido com o Visual Studio 2012. Talvez outros compiladores implementem o enable_shared_from_this de maneira diferente ... *

enable_shared_from_this<T> adiciona um privado weak_ptr<T> instância à Tqual contém a ' única contagem de referência verdadeira ' para a instância de T.

Então, quando você cria um shared_ptr<T> para um novo T *, o ponto fraco_ptr interno do T * é inicializado com uma contagem de ref 1. O novo shared_ptrbasicamente se baseia nisso weak_ptr.

TEm seguida, em seus métodos, pode chamar shared_from_thispara obter uma instância shared_ptr<T>disso para a mesma contagem de referência armazenada internamente . Dessa forma, você sempre tem um lugar onde T*a contagem de ref é armazenada, em vez de ter várias shared_ptrinstâncias que não se conhecem e cada uma pensa que é a shared_ptrresponsável pela contagem de ref Te excluí-la quando a ref -count chega a zero.

Observe que o uso de um boost :: intrusive_ptr não sofre esse problema. Geralmente, é uma maneira mais conveniente de contornar esse problema.

É exatamente o mesmo no c ++ 11 e posterior: é para permitir a capacidade de retornar thiscomo um ponteiro compartilhado, poisthis fornece um ponteiro bruto.

em outras palavras, permite transformar código como este

class Node {
public:
    Node* getParent const() {
        if (m_parent) {
            return m_parent;
        } else {
            return this;
        }
    }

private:

    Node * m_parent = nullptr;
};           

nisso:

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;
};           

Outra maneira é adicionar um weak_ptr<Y> m_stubmembro ao class Y. Então escreva:

shared_ptr<Y> Y::f()
{
    return m_stub.lock();
}

Útil quando você não pode alterar a classe da qual você está derivando (por exemplo, estendendo a biblioteca de outras pessoas). Não se esqueça de inicializar o membro, por exemplo,m_stub = shared_ptr<Y>(this) , , é válido mesmo durante um construtor.

Tudo bem se houver mais stubs como este na hierarquia de herança, isso não impedirá a destruição do objeto.

Editar: Conforme indicado corretamente pelo usuário nobar, o código destruirá o objeto Y quando a atribuição for concluída e as variáveis ​​temporárias forem destruídas. Portanto, minha resposta está incorreta.