Richiama esplicitamente il risultato del distruttore nel comportamento non definito qui?

Question

A mio parere, il seguente codice (da qualche domanda C++) dovrebbe portare a UB, ma sembra che non lo sia. Ecco il codice:

#include <iostream> 
using namespace std; 
class some{ public: ~some() { cout<<"some's destructor"<<endl; } }; 
int main() { some s; s.~some(); } 

e la risposta è:

some's destructor 
some's destructor 

ho imparato modulo C++ faq lite che non dovremmo chiamare esplicitamente distruttore. Penso che dopo la chiamata esplicita al distruttore, l'oggetto s debba essere cancellato. Il programma chiama automaticamente il distruttore al termine, dovrebbe essere UB. Tuttavia, l'ho provato su g ++ e ho ottenuto lo stesso risultato della risposta di cui sopra.

È perché la classe è troppo semplice (nessuna nuova/eliminazione coinvolta)? O non è affatto UB in questo caso?

Answer 1

Il comportamento è indefinito perché il distruttore viene richiamato due volte per lo stesso oggetto:

• volta quando si richiama esplicitamente
• volta quando la portata termina e la variabile automatica è distrutta

Invocare il distruttore su un oggetto la cui durata è terminata comporta un comportamento non definito per C++ 03 §12.4/6:

il comportamento è indefinito se il distruttore viene richiamato per un oggetto la cui vita si è conclusa

vita di un oggetto termina quando il suo distruttore viene chiamato per §3.8/1:

La durata di un oggetto di tipo T termina quando:

- se T è un tipo di classe con un distruttore non banale (12.4), la chiamata distruttore inizia, o

- la memoria che l'oggetto occupa viene riutilizzata o rilasciata.

Si noti che questo significa che se la classe ha un distruttore banale, il comportamento è ben definito, perché la vita di un oggetto di un tale tipo non finisce fino alla sua archiviazione viene rilasciato, che per le variabili automatiche non accade fino alla fine della funzione. Naturalmente, non so perché invocare esplicitamente il distruttore se è banale.

Che cos'è un distruttore banale? §12.4/3 dice:

un distruttore è banale se si tratta di un distruttore implicitamente dichiarata e se:

- tutte le classi base dirette della sua classe hanno distruttori banali e

- per tutti i membri di dati non statici della sua classe che sono di tipo classe (o matrice di essi), ciascuna di queste classi ha un distruttore banale.

Come altri hanno già detto, un possibile risultato di comportamento indefinito è che il programma sembra continuare a funzionare correttamente; un altro possibile risultato è il crash del programma. Tutto può succedere e non ci sono garanzie di sorta.

Answer 2

Il problema qui è che la cancellazione/deallocazione e i distruttori sono costrutti separati e indipendenti. Molto come nuovo/allocazione e costruttori. È possibile fare solo uno dei precedenti senza l'altro.

Nel caso generale, questo scenario non è utile e causa solo confusione con i valori allocati dello stack. Al di sopra della mia testa non riesco a pensare a un buon scenario in cui vorresti farlo (anche se sono sicuro che ce ne sia potenzialmente uno). Tuttavia è possibile pensare a scenari artificiali in cui ciò sarebbe legale.

class StackPointer<T> { 
    T* m_pData; 
public: 
    StackPointer(T* pData) :m_pData(pData) {} 
    ~StackPointer() { 
    delete m_pData; 
    m_pData = NULL; 
    } 
    StackPointer& operator=(T* pOther) { 
    this->~StackPointer(); 
    m_pData = pOther; 
    return this; 
    } 
}; 

Nota: non scrivere mai una classe in questo modo. Avere invece un metodo di rilascio esplicito.

Answer 3

Molto probabilmente funziona bene perché il distruttore non fa riferimento a nessuna variabile membro della classe. Se hai provato a delete una variabile all'interno del distruttore, probabilmente ti troverai nei guai quando viene chiamato automaticamente la seconda volta.

Poi di nuovo, con un comportamento indefinito, chi lo sa? :)

Answer 4

È un comportamento non definito, ma come con qualsiasi UB, una possibilità è che (più o meno) sembra funzionare, almeno per qualche definizione di lavoro.

In sostanza, l'unica volta che è necessario (o si desidera) invocare esplicitamente un distruttore è in congiunzione con il posizionamento nuovo (ovvero, si usa il posizionamento nuovo per creare un oggetto in una posizione specificata e una chiamata esplicita per distruggere quell'oggetto).

Answer 5

Ciò che la funzione principale fa è riservare spazio allo stack, chiamare il costruttore di alcuni e alla fine chiamare il distruttore di alcuni. Questo succede sempre con una variabile locale, qualunque sia il codice inserito all'interno della funzione. Il tuo compilatore non rileverà che hai chiamato manualmente il distruttore.

In ogni caso non è necessario chiamare manualmente il distruttore di un oggetto, ad eccezione degli oggetti creati con posizionamento nuovo.

Answer 6

Da http://www.devx.com/tips/Tip/12684

comportamento indefinito indica che un'implementazione può funzionare anomalo quando un programma raggiunge un certo stato, che quasi senza eccezione è il risultato di un errore. Un comportamento indefinito può manifestarsi come un arresto in fase di esecuzione, uno stato di programma instabile e inaffidabile o, in rari casi, lo può passare inosservato allo.

Nel tuo caso non si blocca perché il distruttore non manipola alcun campo; in realtà, la tua classe non ha alcun membro di dati. Se lo facesse e nel corpo del distruttore lo avessi manipolato in qualsiasi modo, probabilmente otterrai un'eccezione run-time mentre chiamerai il distruttore per la seconda volta.

Answer 7

Credo che se si desidera che il proprio codice sia corretto, è sufficiente chiamare il posizionamento nuovo e riempirlo nuovamente prima di uscire. La chiamata al distruttore non è il problema, è la seconda chiamata al distruttore fatta quando si lascia l'oscilloscopio.

Answer 8

Puoi definire il comportamento indefinito che ti aspetti?Non definito non significa casuale (o catastrofico): il comportamento di un dato programma può essere ripetibile tra le invocazioni, significa solo che non puoi RIVOLGERSI su alcun comportamento particolare perché non è definito e non vi è alcuna garanzia di ciò che accadrà.

Answer 9

È un comportamento non definito. Il comportamento indefinito è la doppia chiamata del distruttore e non con la stessa chiamata del distruttore. Se si modifica il tuo esempio a:

#include <iostream> 
using namespace std; 
class some{ public: ~some() { [INSERT ANY CODE HERE] } }; 
int main() { some s; s.~some(); } 

dove [inserire un codice QUI] può essere sostituito con qualsiasi codice arbitrario. I risultati hanno effetti collaterali imprevedibili, motivo per cui è considerato non definito.