Transizione a C++ 11 dove i distruttori sono implicitamente dichiarati con nient'altro

Question

In C++ 11, un distruttore senza alcuna specifica di eccezione viene implicitamente dichiarato con noexcept, che è una modifica da C++ 03. Pertanto, un codice che usava lanciare dai distruttori in C++ 03 sarebbe comunque ben compilato in C++ 11, ma si arresterebbe in fase di runtime quando tenterà di lanciare da un tale distruttore.

Poiché non vi è alcun errore in fase di compilazione con un tale codice, come potrebbe essere tranquillamente passato a C++ 11, a meno di dichiarare tutti i distruttori esistenti nella base di codice come noexcept(false), che sarebbe davvero eccessivo verboso e intrusivo, o ispezionare ogni distruttore per essere potenzialmente di lancio, il che sarebbe davvero dispendioso in termini di tempo e incline a fare, o catturare e correggere tutti gli arresti anomali in fase di runtime, cosa che non garantirebbe mai tutti questi casi?

Answer 1

Una volta ho passato lo stesso dilemma.

Fondamentalmente quello che ho concluso è che, accettando il fatto che quei distruttori stanno lanciando e semplicemente vivendo con le conseguenze di ciò è di solito molto peggio che passare attraverso il dolore di farli non buttare.

La ragione è che si rischiano stati ancora più volatili e imprevedibili quando si lanciano distruttori.

Ad esempio, ho lavorato a un progetto una volta in cui, per vari motivi, alcuni sviluppatori utilizzavano eccezioni per il controllo del flusso in alcune parti del progetto e funzionava perfettamente per anni. Più tardi, qualcuno ha notato che in una parte diversa del progetto, a volte il client non riusciva a inviare alcuni messaggi di rete che doveva inviare, così hanno creato un oggetto RAII che avrebbe inviato i messaggi nel suo distruttore. A volte il networking generava un'eccezione, quindi questo distruttore RAII avrebbe lanciato, ma chi se ne frega? Non ha memoria da ripulire, quindi non è una perdita.

E ciò funzionerebbe correttamente per il 99% delle volte, tranne quando il percorso di controllo del flusso delle eccezioni si verificava per attraversare il collegamento in rete, che genera anche un'eccezione. E poi, hai due eccezioni live che vengono svolte in una sola volta, quindi "bang sei morto", nelle parole immortali delle FAQ C++.

Onestamente preferirei che il programma si interrompesse all'istante quando un distruttore getta, quindi possiamo parlare con chi ha scritto il distruttore di lancio, piuttosto che provare a mantenere un programma con intenzionalmente a lanciare i distruttori, e questo è il consenso del comitato/comunità sembra. Così hanno fatto questo cambiamento decisivo per aiutarti ad affermare che i tuoi distruttori sono bravi e non lanciano. Potrebbe essere molto lavoro se il tuo codice base ha molti hack, ma se vuoi continuare a svilupparlo e mantenerlo, almeno sullo standard C++ 11, è meglio fare il lavoro di pulizia su i distruttori.

linea di fondo:

Hai ragione, non si può davvero sperare di garantire che a trovare tutte le possibili istanze di un distruttore di lancio. Quindi ci saranno probabilmente degli scenari in cui, quando il tuo codice viene compilato in C++ 11, si bloccherà nei casi in cui non sarebbe conforme allo standard C++ 98. Ma nel complesso, ripulire i distruttori e correre come C++ 11 sarà probabilmente molto più stabile che andare con i distruttori di lancio sui vecchi standard.

Answer 2

Si noti che le regole non sono in realtà così brutali. Il distruttore sarà implicitamente solo noexcept se un distruttore implicitamente dichiarato sarebbe. Pertanto, contrassegnando almeno una classe di base o un tipo di membro come noexcept (false) si avvelenerà il valore noexcept di tutta la gerarchia/aggregato.

#include <type_traits> 

struct bad_guy 
{ 
    ~bad_guy() noexcept(false) { throw -1; } 
}; 

static_assert(!std::is_nothrow_destructible<bad_guy>::value, 
       "It was declared like that"); 

struct composing 
{ 
    bad_guy member; 
}; 

static_assert(!std::is_nothrow_destructible<composing>::value, 
       "The implicity declared d'tor is not noexcept if a member's" 
       " d'tor is not"); 

struct inheriting : bad_guy 
{ 
    ~inheriting() { } 
}; 

static_assert(!std::is_nothrow_destructible<inheriting>::value, 
       "The d'tor is not implicitly noexcept if an implicitly" 
       " declared d'tor wouldn't be. An implicitly declared d'tor" 
       " is not noexcept if a base d'tor is not."); 

struct problematic 
{ 
    ~problematic() { bad_guy {}; } 
}; 

static_assert(std::is_nothrow_destructible<problematic>::value, 
       "This is the (only) case you'll have to look for."); 

Tuttavia, sono d'accordo con Chris Beck che si dovrebbe sbarazzarsi dei tuoi distruttori lancio prima o poi. Possono anche far esplodere il programma C++ 98 nei momenti più scomodi.

Answer 3

Come già accennato, 5gon12eder, esistono alcune regole che determinano un distruttore senza una specifica di eccezione da dichiarare implicitamente come noexcept o noexcept(false). Se il tuo distruttore può lanciare e lasciare che il compilatore decida la sua specifica di eccezione, giocherebbe una roulette, perché ti affidi alla decisione del compilatore influenzata dagli antenati e dai membri della classe, dai loro antenati e membri in modo ricorsivo , che è troppo complesso da tracciare ed è soggetto a modifiche durante l'evoluzione del tuo codice. Pertanto, quando si definisce un distruttore con un corpo che può essere lanciato e nessuna specifica di eccezione, deve essere dichiarato esplicitamente come noexcept(false). D'altra parte, se sei certo che il corpo non può lanciare, puoi dichiararlo più esplicito, noexcept e aiutare il compilatore a ottimizzare, ma fai attenzione se scegli di farlo, perché se un distruttore di un membro/l'antenato della tua classe decide di lanciare, il tuo codice si interromperà in fase di runtime.

Si noti che qualsiasi distruttore o distruttore implicitamente definito con corpi vuoti non pone problemi. Sono implicitamente solo noexcept se tutti i distruttori di tutti i membri e gli antenati sono anche noexcept.

Il modo migliore per procedere con la transizione è quindi trovare tutti i distruttori con corpi non vuoti e nessuna specifica di eccezione e dichiarare ognuno di essi che può lanciare con noexcept(false). Nota che devi solo controllare il corpo del distruttore - qualsiasi tiro immediato o qualsiasi tiro fatto dalle funzioni che chiama, in modo ricorsivo. Non è necessario controllare i distruttori con corpi vuoti, distruttori con una specifica di eccezione esistente o qualsiasi distruttore implicitamente definito. In pratica, non ci sarebbero molti di quelli che devono essere controllati, in quanto l'uso prevalente di questi è semplicemente la liberazione delle risorse.

Dato che sto rispondendo a me stesso, è esattamente quello che ho fatto nel mio caso e non è stato poi così doloroso.