Будет ли разрушение большого списка переполнять мой стек?

Рассмотрим следующую реализацию односвязного списка:

struct node {
    std::unique_ptr<node> next;
    ComplicatedDestructorClass data;
}

Теперь предположим, что я перестал использовать некоторый std::unique_ptr<node> headэкземпляр, который затем выходит из области видимости, вызывая вызов его деструктора.

Будет ли это удар по моему стеку для достаточно больших списков? Справедливо ли предположить, что компилятор будет выполнять довольно сложную оптимизацию (встроенный unique_ptrдеструктор в node, а затем использовать хвостовую рекурсию), что будет намного сложнее, если я сделаю следующее (поскольку dataдеструктор будет запутывать next, делая его трудным чтобы компилятор заметил потенциальную возможность переупорядочения и возможности хвостового вызова):

struct node {
    std::shared_ptr<node> next;
    ComplicatedDestructorClass data;
}

Если dataкаким-то образом есть указатель на его, nodeтогда это может быть даже невозможно для хвостовой рекурсии (хотя, конечно, мы должны стремиться избегать таких нарушений инкапсуляции).

В общем, как можно иначе уничтожить этот список? Мы не можем просмотреть список и удалить «текущий» узел, потому что у общего указателя нет release! Единственный способ - с помощью пользовательского удалителя, который действительно воняет для меня.

Да, это в конечном итоге nodeразрушит ваш стек, если только компилятор не применяет оптимизацию хвостового вызова к деструктору и shared_ptr деструктору. Последнее чрезвычайно зависит от стандартной реализации библиотеки. Например, Microsoft STL никогда этого не сделает, потому что shared_ptrсначала уменьшает счетчик ссылок своего pointee (возможно, уничтожая объект), а затем уменьшает счетчик ссылок своего блока управления (слабый счетчик ссылок). Таким образом, внутренний деструктор не является хвостовым вызовом. Это также виртуальный вызов , который снижает вероятность его оптимизации.

Типичные списки решают эту проблему, не имея один узел, владеющий другим, а имея один контейнер, который владеет всеми узлами, и использует цикл для удаления всего в деструкторе.

Поздний ответ, но так как никто не предоставил его ... Я столкнулся с той же проблемой и решил ее, используя собственный деструктор:

virtual ~node () throw () {
    while (next) {
        next = std::move(next->next);
    }
}

Если у вас действительно есть список , т. Е. Каждому узлу предшествует один узел, и у него самое большее один подписчик, а ваш listуказатель на первый node, то вышеприведенное должно работать.

Если у вас есть нечеткая структура (например, ациклический граф), вы можете использовать следующее:

virtual ~node () throw () {
    while (next && next.use_count() < 2) {
        next = std::move(next->next);
    }
}

Идея в том, что когда вы делаете:

next = std::move(next->next);

Старый общий указатель nextуничтожен (потому что use_countон сейчас 0), и вы указываете на следующее. Это делает то же самое, что деструктор по умолчанию, за исключением того, что он делает это итеративно, а не рекурсивно и, таким образом, избегает переполнения стека.

Честно говоря, я не знаком с алгоритмом освобождения смарт-указателей любого компилятора C ++, но я могу представить простой нерекурсивный алгоритм, который это делает. Учти это:

• У вас есть очередь умных указателей, ожидающих освобождения.
• У вас есть функция, которая берет первый указатель и освобождает его, и повторяет это до тех пор, пока очередь не станет пустой.
• Если умный указатель нуждается в освобождении, он помещается в очередь и вызывается вышеупомянутая функция.

Следовательно, у стека не было бы шансов переполниться, и это намного проще, чем оптимизировать рекурсивный алгоритм.

Я не уверен, вписывается ли это в философию «умных указателей с почти нулевой стоимостью».

Я полагаю, что то, что вы описали, не приведет к переполнению стека, но вы можете попытаться создать умный эксперимент, чтобы доказать, что я неправ.

ОБНОВИТЬ

Ну, это доказывает неправильность того, что я написал ранее:

#include <iostream>
#include <memory>

using namespace std;

class Node;

Node *last;
long i;

class Node
{
public:
   unique_ptr<Node> next;
   ~Node()
   {
     last->next.reset(new Node);
     last = last->next.get();
     cout << i++ << endl;
   }
};

void ignite()
{
    Node n;
    n.next.reset(new Node);
    last = n.next.get();
}

int main()
{
    i = 0;
    ignite();
    return 0;
}

Эта программа вечно строит и деконструирует цепочку узлов. Это вызывает переполнение стека.