¿Cuál es la utilidad de `enable_shared_from_this`?

Me encontré enable_shared_from_thismientras leía los ejemplos de Boost.Asio y después de leer la documentación todavía estoy perdido por cómo se debe usar correctamente. ¿Puede alguien darme un ejemplo y una explicación de cuándo usar esta clase tiene sentido?

Le permite obtener una shared_ptrinstancia válida para this, cuando todo lo que tiene es this. Sin él, no tendría forma de obtener un shared_ptra this, a menos que ya tuviera uno como miembro. Este ejemplo de la documentación de 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
}

El método f()devuelve un válido shared_ptr, a pesar de que no tenía una instancia miembro. Tenga en cuenta que no puede simplemente hacer esto:

class Y: public enable_shared_from_this<Y>
{
public:

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

El puntero compartido que este devuelto tendrá un recuento de referencia diferente del "correcto", y uno de ellos terminará perdiendo y manteniendo una referencia colgante cuando se elimine el objeto.

enable_shared_from_thisse ha convertido en parte del estándar C ++ 11. También puede obtenerlo desde allí, así como desde boost.

del artículo del Dr. Dobbs sobre punteros débiles, creo que este ejemplo es más fácil de entender (fuente: http://drdobbs.com/cpp/184402026 ):

... un código como este no funcionará correctamente:

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

Ninguno de los dos shared_ptrobjetos conoce al otro, por lo que ambos intentarán liberar el recurso cuando sean destruidos. Eso generalmente lleva a problemas.

Del mismo modo, si una función miembro necesita un shared_ptrobjeto que posee el objeto al que se está llamando, no puede crear un objeto sobre la marcha:

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 tiene el mismo problema que el ejemplo anterior, aunque en una forma más sutil. Cuando se construye, el shared_ptobjeto r sp1posee el recurso recién asignado. El código dentro de la función miembro S::dangerousno conoce ese shared_ptrobjeto, por lo que el shared_ptrobjeto que devuelve es distinto sp1. Copiar el nuevo shared_ptrobjeto a sp2no ayuda; cuando está sp2fuera de alcance, liberará el recurso, y cuando sp1salga del alcance, volverá a liberar el recurso.

La forma de evitar este problema es usar la plantilla de clase enable_shared_from_this. La plantilla toma un argumento de tipo de plantilla, que es el nombre de la clase que define el recurso administrado. Esa clase debe, a su vez, derivarse públicamente de la plantilla; Me gusta esto:

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

Cuando haga esto, tenga en cuenta que el objeto al que llama shared_from_thisdebe ser propiedad de un shared_ptrobjeto. Esto no funcionará:

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

Aquí está mi explicación, desde una perspectiva de tuercas y pernos (la respuesta principal no 'hizo clic' conmigo). * Tenga en cuenta que este es el resultado de investigar el origen de shared_ptr y enable_shared_from_this que viene con Visual Studio 2012. Quizás otros compiladores implementen enable_shared_from_this de manera diferente ... *

enable_shared_from_this<T>privada añade un weak_ptr<T>ejemplo de Tlo que sostiene el ' verdadero contador de referencia ' para la instancia de T.

Entonces, cuando creas un shared_ptr<T>nuevo en un nuevo T *, el débil_ptr interno de ese T * se inicializa con un recuento de 1. El nuevo shared_ptrbásicamente retrocede en esto weak_ptr.

Tpuede, entonces, en sus métodos, llamar shared_from_thispara obtener una instancia de shared_ptr<T>ese respaldo en el mismo recuento de referencia almacenado internamente . De esta manera, siempre tiene un lugar donde T*se almacena el recuento de referencias en lugar de tener varias shared_ptrinstancias que no se conocen entre sí, y cada una piensa que son las shared_ptrencargadas de contarlas Ty eliminarlas cuando su referencia -cuenta llega a cero.

Tenga en cuenta que el uso de boost :: intrusive_ptr no sufre este problema. Esta suele ser una forma más conveniente de solucionar este problema.

Es exactamente lo mismo en c ++ 11 y versiones posteriores: es para permitir la posibilidad de regresar thiscomo un puntero compartido, ya que thisle da un puntero sin formato.

en otras palabras, te permite activar código como este

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

private:

    Node * m_parent = nullptr;
};           

dentro de esto:

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

Otra forma es agregar un weak_ptr<Y> m_stubmiembro al class Y. Luego escribir:

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

Útil cuando no puede cambiar la clase de la que deriva (por ejemplo, ampliar la biblioteca de otras personas). No olvide inicializar el miembro, por ejemplo m_stub = shared_ptr<Y>(this), por , es válido incluso durante un constructor.

Está bien si hay más trozos como este en la jerarquía de herencia, no evitará la destrucción del objeto.

Editar: como lo señaló correctamente el usuario nobar, el código destruiría el objeto Y cuando finalice la asignación y se destruyan las variables temporales. Por lo tanto mi respuesta es incorrecta.