distruttore di un oggetto statico costruito all'interno il distruttore di un altro oggetto statico

Question

ho alcuni problemi con distruttore, nel codice seguente:

#include <stdlib.h> 
#include <cstdio> 

class Foo2 
{ 
    public: 
     Foo2() { printf("foo2 const\n"); } 

     ~Foo2() 
     { 
      printf("foo2 dest\n"); // <--- wasn't called for bionic libc 
     } 
}; 

static Foo2& GetFoo2() 
{ 
    static Foo2 foo2; 
    printf ("return foo2\n"); 
    return foo2; 
} 

class Foo1 
{ 
    public: 
     Foo1() { printf("foo1 const\n"); } 

     ~Foo1() 
     { 
      printf("foo1 dest\n"); 
      GetFoo2(); 
     } 
}; 

int main(int argc, const char* argv[]) 
{ 
     printf("main 1 \n"); 
     static Foo1 anotherFoo; 
     printf("main 2 \n"); 
} 

Perché distruttore per foo2 non è stato chiamato per bionic ed è stato per glibc?

EDIT
Uscita per bionico:

main 1 
foo1 const 
main 2 
foo1 dest 
foo2 const 
return foo2 

Debug Info:

(gdb) break 22 
Breakpoint 1 at 0x8048858: file test.C, line 22. 
(gdb) info breakpoints 
Num  Type   Disp Enb Address What 
1  breakpoint  keep y 0x08048858 in Foo2::~Foo2() at test.C:22 
(gdb) cont 
[ exited with code 0] 

Answer 1

Penso che il tuo codice abbia un comportamento indefinito, sebbene lo standard non sia molto chiaro (o non lo trovo nello standard ). Il codice costruisce un nuovo oggetto statico nel distruttore di un oggetto statico. La norma non affronta questo caso, ma:

1. Essa dice che distruttori devono essere richiamati nel inverso ordine di costruzione. Nel tuo caso, ciò implicherebbe che l'oggetto statico in GetFoo2 deve essere destrutturato prima che fosse costruito, che è contraddittorio.

2. Il testo in §3.6/3 descrive il sequenziamento dei distruttori e le funzioni registrate con atexit. I requisiti sono tali da dover utilizzare lo stesso meccanismo di registrazione per ciascuno. E chiamare atexit dopo aver chiamato exit (o restituito da main) è un comportamento non definito.

3. C'è anche §3.6/2, che dice che "Se una funzione contiene un oggetto blocco-portata della durata statica o di stoccaggio filo che è stata distrutta e la funzione viene chiamata durante l' distruzione di un oggetto con memorizzazione statica o thread durata, il programma ha un comportamento indefinito se il flusso del controllo passa attraverso la definizione dell'oggetto oggetto blockscope distrutto in precedenza ". Questa frase parla di oggetti danneggiati danneggiati, ma non ci vuole molta immaginazione per pensare a che l'assenza di oggetti "non ancora costruiti" è solo una supervisione .

Alla fine, direi che il mio primo punto di cui sopra è conclusiva con per quanto riguarda l'intenzione. In §1.3.24, c'è una nota (non normativa, ma indicativa di intenti) "Si può prevedere un comportamento non definito quando questa norma internazionale omette qualsiasi de fi nizione esplicita del comportamento o quando un programma utilizza un costrutto errato o dati errati ". In questo caso, l'unica descrizione del comportamento richiesto è impossibile (dato che non è possibile distruggere un oggetto prima che sia stato creato) e lo standard non dice nulla su come questo dovrebbe essere risolto.

Answer 2

Tutte le istanze che vedo in questo codice sono statici.

Di conseguenza il loro distruttore viene chiamato alla fine dell'eseguibile, dopo che il main è finito.

se il distruttore non è stato chiamato, allora era un bug.

Answer 3

l'oggetto statico verrà distrutto quando il programma esiste. metti un punto di interruzione a ~Foo2(), lo vedrai o scriverai un log in un file per aiutarti a diagnosticarlo. Se davvero non viene chiamato, si tratta di un bug del compilatore.

Ed è divertente per caricare una foto per rispondere a una domanda.

Answer 4

C++ 11 3.6.3/1: distruttori per gli oggetti inizializzati [...] con durata di conservazione statica sono chiamati come risultato di ritorno da main

Nel punto in cui la il programma restituisce da main, anotherFoo è stato inizializzato; ma foo2 non ha, dal momento che non è stato inizializzato fino alla prima chiamata a GetFoo2 durante la distruzione di anotherFoo. Pertanto, un'interpretazione rigorosa delle regole implicherebbe che il suo distruttore non debba essere chiamato.