У чому полягає корисність `enable_shared_from_this`?

Я перебігав enable_shared_from_this, читаючи приклади Boost.Asio і після прочитання документації я все ще втрачаю, як це правильно використовувати. Чи може хтось, будь ласка, надати мені приклад та пояснення щодо використання цього класу має сенс.

Це дозволяє вам отримати дійсний shared_ptrекземпляр this, коли все, що у вас є this. Без нього ви не мали б ніякого способу отримувати shared_ptrдо this, якщо ви вже мали один в якості члена. Цей приклад із документації для підвищення для 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
}

Метод f()повертає дійсний shared_ptr, навіть не маючи примірника члена. Зауважте, що ви не можете просто зробити це:

class Y: public enable_shared_from_this<Y>
{
public:

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

Спільний покажчик, який повернувся, матиме інший підрахунок посилань від "належного", і один із них втратить і матиме звисаючу посилання, коли об'єкт буде видалений.

enable_shared_from_thisстав частиною стандарту C ++ 11. Ви також можете отримати його як звідти, так і з прискорення.

зі статті доктора Доббса про слабкі покажчики, я думаю, що цей приклад легше зрозуміти (джерело: http://drdobbs.com/cpp/184402026 ):

... такий код не працює належним чином:

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

Жоден з двох shared_ptrоб'єктів не знає про інший, тому обидва намагатимуться звільнити ресурс, коли вони будуть знищені. Зазвичай це призводить до проблем.

Аналогічно, якщо функції-члену потрібен shared_ptrоб'єкт, який належить об'єкту, до якого його викликають, він не може просто створити об'єкт на льоту:

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

Цей код має ту саму проблему, що і в попередньому прикладі, хоча у більш тонкій формі. Коли він побудований, shared_ptr об'єкту sp1належить щойно виділений ресурс. Код всередині функції-члена S::dangerousне знає про цей shared_ptrоб'єкт, тому shared_ptrоб'єкт, від якого він повертається, відрізняється від sp1. Копіювання нового shared_ptrоб’єкта sp2не допомагає; коли sp2вийде за рамки, він вивільнить ресурс, а коли sp1вийде за межі, знову випустить ресурс.

Спосіб уникнути цієї проблеми - використовувати шаблон класу enable_shared_from_this. Шаблон приймає один аргумент типу шаблону, який є іменем класу, який визначає керований ресурс. Цей клас, у свою чергу, повинен бути публічно виведений із шаблону; подобається це:

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

Роблячи це, майте на увазі, що об’єкт, на який ви телефонуєте, shared_from_thisповинен належати shared_ptrоб'єкту. Це не спрацює:

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

Ось моє пояснення з точки зору гайок і болтів (головна відповідь не «клацала» зі мною). * Зауважте, що це результат дослідження джерела для shared_ptr та enable_shared_from_this, який поставляється з Visual Studio 2012. Можливо, інші компілятори реалізують enable_shared_from_this по-різному ... *

enable_shared_from_this<T>додає приватний weak_ptr<T>екземпляр, до Tякого міститься " один справжній посилання " для екземпляра T.

Отже, коли ви вперше створюєте shared_ptr<T>на новій T *, внутрішній слабкий_ptr T * ініціалізується зі зворотним рахунком 1. Новий в shared_ptrосновному спирається на це weak_ptr.

Tможе, у своїх методах, викликати shared_from_thisотримання екземпляра shared_ptr<T>цього списку на той самий внутрішньо збережений контрольний номер . Таким чином, у вас завжди є одне місце, де T*зберігається повторний підрахунок, а не декілька shared_ptrекземплярів, які не знають один про одного, і кожен думає, що вони є тим, shared_ptrхто відповідає за підрахунок посилання Tта видалення його, коли їх посилання -кілька досягає нуля.

Зауважте, що використання boost :: intrusive_ptr не страждає від цієї проблеми. Це часто більш зручний спосіб подолати цю проблему.

Це точно так само в c ++ 11 і пізніших версіях: це увімкнути можливість повернення thisяк спільний покажчик, оскільки thisдає вам необроблений покажчик.

інакше кажучи, це дозволяє вам перетворити такий код

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

private:

    Node * m_parent = nullptr;
};           

в це:

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

Інший спосіб - додати weak_ptr<Y> m_stubчлена до class Y. Тоді пиши:

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

Корисно, коли ви не можете змінити клас, з якого ви походите (наприклад, розширення бібліотеки інших людей). Не забувайте ініціалізувати елемент, наприклад m_stub = shared_ptr<Y>(this), його дія діє навіть під час конструктора.

Добре, якщо в ієрархії спадкування є більше таких заглушок, як це, це не завадить знищити об'єкт.

Редагувати: Як правильно вказав користувач nobar, код знищить об'єкт Y, коли призначення буде закінчено, а тимчасові змінні знищені. Тому моя відповідь неправильна.