Distruggere un grande elenco trabocca il mio stack?

Considera la seguente implementazione dell'elenco collegato singolarmente:

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

Ora supponiamo che smetta di usare qualche std::unique_ptr<node> headistanza che poi esca dall'ambito, facendo chiamare il suo distruttore.

Questo farà esplodere il mio stack per liste sufficientemente grandi? È lecito ritenere che il compilatore eseguirà un'ottimizzazione piuttosto complicata (inline unique_ptr's destructor in node's, quindi usa la ricorsione della coda), che diventa molto più difficile se faccio quanto segue (dal momento che il datadistruttore potrebbe offuscare quello next, rendendolo difficile per il compilatore notare il potenziale riordino e opportunità di coda):

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

Se in dataqualche modo ha un puntatore al suo, nodeallora potrebbe anche essere impossibile per la ricorsione della coda (anche se ovviamente dovremmo cercare di evitare tali violazioni dell'incapsulamento).

In generale, come si può distruggere questa lista altrimenti, allora? Non possiamo attraversare l'elenco ed eliminare il nodo "corrente" perché il puntatore condiviso non ha un release! L'unico modo è con un deleter personalizzato, che è davvero maleodorante per me.

Sì, questo alla fine farà esplodere il tuo stack, a meno che il compilatore non applichi semplicemente un'ottimizzazione della coda al nodedistruttore e shared_ptr al distruttore. Quest'ultimo dipende in larga misura dall'implementazione della libreria standard. L'STL di Microsoft, ad esempio, non lo farà mai, perché shared_ptrprima decrementa il conteggio dei riferimenti della sua punta (possibilmente distruggendo l'oggetto) e poi diminuisce il conteggio dei riferimenti del blocco di controllo (il conteggio dei riferimenti deboli). Quindi il distruttore interno non è un richiamo alla coda. È anche una chiamata virtuale , il che rende ancora meno probabile che venga ottimizzata.

Gli elenchi tipici risolvono questo problema non avendo un nodo proprietario del successivo, ma avendo un contenitore che possiede tutti i nodi e utilizza un ciclo per eliminare tutto nel distruttore.

Risposta tardiva ma dal momento che nessuno lo ha fornito ... Ho riscontrato lo stesso problema e risolto utilizzando un distruttore personalizzato:

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

Se hai davvero un elenco , cioè ogni nodo è preceduto da un nodo e ha al massimo un follower, e il tuo listè un puntatore al primo node, quanto sopra dovrebbe funzionare.

Se si dispone di una struttura sfocata (ad esempio un grafico aciclico), è possibile utilizzare quanto segue:

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

L'idea è che quando lo fai:

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

Il vecchio puntatore condiviso nextviene distrutto (perché use_countè ora 0) e si punta a quanto segue. Questo fa esattamente lo stesso del distruttore predefinito, tranne che lo fa in modo iterativo invece che ricorsivo e quindi evita lo stack overflow.

Ad essere sincero, non ho familiarità con l'algoritmo di deallocazione del puntatore intelligente di qualsiasi compilatore C ++, ma posso immaginare un algoritmo semplice e non ricorsivo che lo faccia. Considera questo:

• Hai una coda di puntatori intelligenti in attesa di deallocazione.
• Si dispone di una funzione che accetta il primo puntatore e lo posiziona e lo ripete fino a quando la coda è vuota.
• Se un puntatore intelligente necessita di deallocazione, viene inserito nella coda e viene chiamata la funzione sopra.

Quindi non ci sarebbe alcuna possibilità che lo stack traboccasse, ed è molto più semplice ottimizzare un algoritmo ricorsivo.

Non sono sicuro che ciò rientri nella filosofia "puntatori intelligenti a costo quasi zero".

Immagino che ciò che hai descritto non provocherebbe un overflow dello stack, ma potresti provare a costruire un esperimento intelligente per dimostrarmi che mi sbaglio.

AGGIORNARE

Bene, questo dimostra che cosa ho scritto in precedenza è sbagliato:

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

Questo programma costruisce e decostruisce eternamente una catena di nodi. Causa overflow dello stack.