Jaka jest użyteczność `enable_shared_from_this`?

Natknąłem się enable_shared_from_thisna czytając przykłady Boost.Asio i po przeczytaniu dokumentacji wciąż jestem zagubiony w tym, jak należy to właściwie wykorzystać. Czy ktoś może mi podać przykład, a wyjaśnienie, kiedy korzystam z tej klasy, ma sens.

Umożliwia uzyskanie prawidłowej shared_ptrinstancji this, gdy wszystko, co masz, to this. Bez niego nie byłoby sposobu, aby dostać się shared_ptrdo this, chyba że masz go już jako członek. Ten przykład z dokumentacji doładowania dla 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
}

Metoda f()zwraca poprawną wartość shared_ptr, mimo że nie miała instancji elementu. Pamiętaj, że nie możesz tego po prostu zrobić:

class Y: public enable_shared_from_this<Y>
{
public:

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

Współdzielony wskaźnik, który to zwróci, będzie miał inną liczbę odniesień niż „właściwy”, a jeden z nich straci i utrzyma wiszące odniesienie, gdy obiekt zostanie usunięty.

enable_shared_from_thisstał się częścią standardu C ++ 11. Możesz także pobrać go stamtąd, a także z doładowania.

z artykułu dr Dobbs na temat słabych wskaźników, myślę, że ten przykład jest łatwiejszy do zrozumienia (źródło: http://drdobbs.com/cpp/184402026 ):

... taki kod nie działa poprawnie:

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

Żaden z dwóch shared_ptrobiektów nie wie o drugim, więc oba będą próbowały uwolnić zasób, gdy zostaną zniszczone. To zwykle prowadzi do problemów.

Podobnie, jeśli funkcja członka potrzebuje shared_ptrobiektu będącego właścicielem obiektu, do którego jest wywoływana, nie może po prostu utworzyć obiektu w locie:

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

Ten kod ma ten sam problem, co we wcześniejszym przykładzie, chociaż w bardziej subtelnej formie. Podczas budowy shared_ptobiekt r sp1jest właścicielem nowo przydzielonego zasobu. Kod wewnątrz funkcji S::dangerousskładowej nie wie o tym shared_ptrobiekcie, więc shared_ptrobiekt, który zwraca, różni się od niego sp1. Kopiowanie nowego shared_ptrobiektu do sp2nie pomaga; gdy sp2wyjdzie poza zakres, zwolni zasób, a gdy sp1wyjdzie poza zakres, ponownie zwolni zasób.

Sposobem uniknięcia tego problemu jest użycie szablonu klasy enable_shared_from_this. Szablon przyjmuje jeden argument typu szablonu, który jest nazwą klasy definiującej zarządzany zasób. Ta klasa musi z kolei pochodzić publicznie z szablonu; lubię to:

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

Gdy to zrobisz, pamiętaj, że obiekt, do którego dzwonisz, shared_from_thismusi być własnością shared_ptrobiektu. To nie zadziała:

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

Oto moje wyjaśnienie z perspektywy orzechów (pierwsza odpowiedź nie „kliknęła” ze mną). * Zauważ, że jest to wynik badania źródła shared_ptr i enable_shared_from_thth, który jest dostarczany z Visual Studio 2012. Być może inne kompilatory implementują enable_shared_from_this inaczej inaczej ... *

enable_shared_from_this<T>dodaje prywatną weak_ptr<T>instancję, do Tktórej przypisano „ jedną prawdziwą liczbę referencji ” dla instancji T.

Tak więc, kiedy po raz pierwszy tworzysz shared_ptr<T>nowy na T *, wewnętrzny słaby_ptr T * jest inicjalizowany z przeliczeniem 1. Nowy w shared_ptrzasadzie się na to powraca weak_ptr.

Tnastępnie w swoich metodach może wywoływać, shared_from_thisaby uzyskać instancję shared_ptr<T>tego zaplecza na tej samej wewnętrznie przechowywanej liczbie referencji . W ten sposób zawsze masz jedno miejsce, w którym T*przechowywana jest liczba odwołań, a nie wiele shared_ptrwystąpień, które nie znają się nawzajem, i każdy uważa, że ​​to one są shared_ptrodpowiedzialne za przeliczanie Ti usuwanie go, gdy ich odwołanie -licznik osiąga zero.

Zauważ, że użycie boost :: intrusive_ptr nie cierpi z powodu tego problemu. Jest to często wygodniejszy sposób na obejście tego problemu.

Dokładnie tak samo jest w c ++ 11 i późniejszych wersjach: od tego momentu ma możliwość powrotu thisjako wskaźnik wspólnythis daje surowy wskaźnik.

innymi słowy, pozwala zmienić kod w ten sposób

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

private:

    Node * m_parent = nullptr;
};           

zaangażowany w to:

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

Innym sposobem jest dodanie weak_ptr<Y> m_stubczłonka do class Y. Następnie napisz:

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

Przydatne, gdy nie możesz zmienić klasy, z której wywodzisz (np. Rozszerzając bibliotekę innych osób). Nie zapomnij zainicjować członka, np. Przezm_stub = shared_ptr<Y>(this) , że jest on ważny nawet podczas konstruktora.

Jest OK, jeśli istnieje więcej kodów pośredniczących w hierarchii dziedziczenia, nie zapobiegnie to zniszczeniu obiektu.

Edycja: Jak poprawnie wskazał nobar użytkownika, kod zniszczyłby obiekt Y po zakończeniu przypisania i zniszczeniu zmiennych tymczasowych. Dlatego moja odpowiedź jest nieprawidłowa.