Wie werden Ausnahmen, die auf dem Stack zugewiesen sind, über ihren Gültigkeitsbereich hinaus erfasst?

Question

Im folgenden Code wird die stackbasierte Variable 'ex' in einer Funktion ausgelöst und abgefangen, die über den Bereich hinausgeht, in dem ex deklariert wurde. Das erscheint mir etwas seltsam, da (AFAIK) stack-basierte Variablen nicht außerhalb des Gültigkeitsbereichs verwendet werden können, in dem sie deklariert wurden (der Stack wird abgewickelt).

void f() { 
    SomeKindOfException ex(...); 
    throw ex; 
} 

void g() { 
    try { 
     f(); 
    } catch (SomeKindOfException& ex) { 
     //Handling code... 
    } 
} 

Ich habe eine print-Anweisung zu SomeKindOfException Destruktor hinzugefügt und es zeigt, dass ex zerstört wird, wenn es außerhalb des Gültigkeitsbereiches in f geht(), aber dann ist es in g gefangen() und zerstört wieder, sobald es aus geht Umfang dort auch.

Irgendwelche Hilfe?

Answer 1

Das Ausnahmeobjekt wird an einen speziellen Ort kopiert, um den Stapel abzuwickeln. Der Grund dafür, dass Sie zwei Zerstörungen sehen, liegt darin, dass beim Beenden von f() die ursprüngliche Ausnahme zerstört wird und beim Beenden von g() die Kopie zerstört wird.

Answer 2

Das Objekt wird in ein Exception-Objekt kopiert, das das Stack-Abwickeln überlebt. Wo die Erinnerung für dieses Objekt herkommt, ist nicht spezifiziert. Für großes Objekt wird es wahrscheinlich malloc ed sein, und für kleinere Objekte könnte die Implementierung einen vorher zugewiesenen Puffer haben (ich könnte mir vorstellen, dass dies für eine bad_alloc Ausnahme verwendet werden könnte).

Der Referenz ex wird dann auf dieses Objekt Ausnahme gebunden, die eine vorübergehende (es keinen Namen hat).

Answer 3

Da die Spezifikation explizit angibt, dass ein temporäres Objekt anstelle des Operanden throw erstellt wird.

Answer 4

C++ Standard-15.1/4:

Der Speicher für die temporäre Kopie der Ausnahme geworfen wurde in einer nicht spezifizierten Weise zugeordnet ist, mit Ausnahme des in 3.7.3.1 festgestellt. Das temporäre bleibt bestehen, solange ein Handler für diese Ausnahme ausgeführt wird. Insbesondere, wenn ein Handler durch Ausführen eines Wurfs beendet wird; Anweisung, die Kontrolle an einen anderen Handler für die gleiche Ausnahme übergibt, so dass das temporäre bleibt. Wenn der letzte für die Ausnahme ausgeführte Handler auf andere Weise als throw beendet wird; das temporäre Objekt wird zerstört und die Implementierung kann den Speicher für das temporäre Objekt freigeben; Eine solche Freigabe wird auf unbestimmte Weise vorgenommen. Die Zerstörung erfolgt unmittelbar nach der Zerstörung des in der Exception-Deklaration im Handler deklarierten Objekts.

Es gibt nichts mehr zu sagen.

Answer 5

Wenn Sie ex abwerfen, wird es an einen speziellen Speicherort kopiert, der für ausgelöste Ausnahmeobjekte verwendet wird. Eine solche Kopie wird vom normalen Kopierkonstruktor ausgeführt.

können Sie diese leicht sehen aus diesem Beispiel:

#include <iostream> 

void ThrowIt(); 

class TestException 
{ 
    public: 
    TestException() 
    { 
     std::cerr<<this<<" - inside default constructor"<<std::endl; 
    } 

    TestException(const TestException & Right) 
    { 
     (void)Right; 
     std::cerr<<this<<" - inside copy constructor"<<std::endl; 
    } 

    ~TestException() 
    { 
     std::cerr<<this<<" - inside destructor"<<std::endl;  
    } 
}; 

int main() 
{ 
    try 
    { 
     ThrowIt(); 
    } 
    catch(TestException & ex) 
    { 
     std::cout<<"Caught exception ("<<&ex<<")"<<std::endl; 
    } 
    return 0; 
} 

void ThrowIt() 
{ 
    TestException ex; 
    throw ex; 
} 

Beispielausgabe:

matteo@teolapubuntu:~/cpp/test$ g++ -O3 -Wall -Wextra -ansi -pedantic ExceptionStack.cpp -o ExceptionStack.x 
matteo@teolapubuntu:~/cpp/test$ ./ExceptionStack.x 
0xbf8e202f - inside default constructor 
0x9ec0068 - inside copy constructor 
0xbf8e202f - inside destructor 
Caught exception (0x9ec0068) 
0x9ec0068 - inside destructor 

By the way, können Sie hier sehen, dass der Speicherplatz für das geworfene Objekt verwendet (0x09ec0068) ist definitiv weit entfernt von dem des ursprünglichen Objekts (0xbf8e202f): der Stapel hat wie üblich hohe Adressen, während der Speicher, der für das geworfene Objekt verwendet wird, ziemlich tief im virtuellen Adressraum ist. Dies ist jedoch ein Implementierungsdetail, da der Standard, wie andere Antworten darauf hingewiesen haben, nichts darüber aussagt, wo der Speicher für das geworfene Objekt sein sollte und wie es zugewiesen werden sollte.

Answer 6

Zusätzlich zu dem, was der Standard in 15.1/4 sagt ("Ausnahmebehandlung/Auslösen einer Ausnahme") - dass der Speicher für die temporäre Kopie der ausgelösten Ausnahme in unspezifizierter Weise zugeordnet wird - ein paar andere Bits von Sicht, wie das Ausnahmeobjekt zugeordnet sind:

• 3.7.3.1/4 („Zuordnungsfunktionen“) der Standard zeigt an, dass das Objekt Ausnahme kann nicht durch einen Ausdruck oder new einen Anruf zu einem zugeordnet werden 'globale Zuweisungsfunktion' (dh eine operator new() Ersetzung). Beachten Sie, dass malloc() keine "globale Zuweisungsfunktion" ist, wie im Standard definiert, so dass malloc() definitiv eine Option für die Zuweisung des Ausnahmeobjekts ist.

• "Wenn eine Ausnahme ausgelöst wird, wird das Ausnahmeobjekt erstellt und ein im Allgemeinen auf irgendeine Art von Ausnahmedaten Stapel abgelegt" (Stanley Lippman, "im Inneren des C++ Objektmodell" - 7.2 Exception Handling)

• Aus Stroustrups "Die C++ Programmiersprache, 3. Ausgabe": "Eine C++ Implementierung ist erforderlich, um genug Speicher zu haben, um bei Erschöpfung des Speichers bad_alloc zu werfen. Es ist jedoch möglich, dass das Auslösen einer anderen Ausnahme Speichermüdigkeit verursacht. "(14.4.5 Ressourcen Erschöpfung); und "Die Implementierung kann eine Vielzahl von Strategien zum Speichern und Übertragen von Ausnahmen anwenden. Es ist jedoch sichergestellt, dass genügend Speicher vorhanden ist, damit new die standardmäßige Ausnahme wegen Speicherauslastung, bad_alloc, auslösen kann" (14.3 Catching Exceptions) .

Beachten Sie, dass die Angebote von Stroustrup vor-Standard sind. Ich finde es interessant, dass der Standard nicht die Garantie zu geben scheint, die Stroustrup für wichtig hielt, um sie zweimal zu erwähnen.