try {....} catch (..) nur dann, wenn eine bestimmte Kompilierung Ausdruck wahr ist

Question

Hier ist, was wir

try { 
    std::uninitialized_copy(...); 
} catch(...) { 
    if(!boost::has_trivial_destructor<T>::value) { 
     // some cleanup to do here... 
    } 
    throw; 
} 

Wir fragen uns, ob die try/catch hat Kosten zu tun versuchen, wenn Die Kompilierzeitkonstante in if ist falsch.

Kann der Compiler innerhalb seiner "as-if" -Rechte den try catch entfernen und sich so verhalten, als ob der std::uninitialized_copy Aufruf ohne try um ihn herum erschienen wäre?

Oder ist in den C++ - Spezifikationen etwas versteckt, das den Compiler benötigt, um es hier zu lassen? Stellen Sie sich als Beispiel eine hypothetische surrounding_try_blocks()-Funktion vor, die die dynamische umgebende Anzahl von try-Blöcken um einen Frame zurückgibt.

Answer 1

Im Folgenden habe ich die Kosten für die Verwendung der Ausnahme zusammengefasst, die ich aus verschiedenen Quellen zusammengestellt habe. Was du in deinem zweiten Punkt fragst, ist mir nicht sehr klar. Also dachte ich, es wäre besser, alles durchzugehen. Hoffe, du würdest etwas von deiner Wichtigkeit auswählen.

Um Ausnahmen zur Laufzeit zu behandeln, müssen Programme eine beträchtliche Menge an Buchhaltung führen. Sie müssen an jedem Punkt während der Ausführung in der Lage sein, die Objekte zu identifizieren, die zerstört werden müssen, wenn eine Ausnahme ausgelöst wird. sie müssen jeden Ein- und Ausgang eines Versuchsblocks notieren; und für jeden try-Block müssen sie die zugehörigen catch-Klauseln und die Arten von Ausnahmen, die diese Klauseln verarbeiten können, verfolgen.

Es gibt Dinge, die Sie bezahlen, auch wenn Sie keine Ausnahmebehandlungsfunktionen verwenden. Sie bezahlen den Speicherplatz, der von den Datenstrukturen benötigt wird, um zu verfolgen, welche Objekte vollständig aufgebaut sind, und zahlen Sie für die Zeit, die benötigt wird, um diese Datenstrukturen auf dem neuesten Stand zu halten. Diese Kosten sind normalerweise ziemlich bescheiden.

Trotzdem ohne Unterstützung kompilierte Programme für Ausnahmen sind sowohl der Regel schneller und kleiner als ihre Pendants mit Unterstützung

Ausnahmen zusammengestellt

Answer 2

Von 15,1/8 finden wir

Ein Wurf-Ausdruck ohne Operand rethrows die derzeit gehandhabte Ausnahme (15.3). Die Ausnahme wird mit dem vorhandenen temporär reaktiviert; kein neues temporäres Ausnahmeobjekt wird ... erstellt klar für mich

diesen ziemlich impliziert, dass die Bewertung des boost::has_trivial_destructor<T>::value unter der Annahme, kann trivialerweise keine Nebenwirkungen haben, gezeigt wird, dass der Compiler in der Lage sein soll, dass die gesamte Masse leicht, um zu bestimmen Der Catch ist nicht ausführbar und das gesamte Konstrukt kann weg optimiert werden. Mir ist kein Compiler bekannt, der dies jedoch tut/tut.

Mein einziger (geringfügiger) Zweifel ist, ob die Sprache das Löschen und Zurücksetzen von std::uncaught_exception() in die "as-if" -Klausel fallen lässt.

Answer 3

Ich habe keine Ahnung, was der Compiler tun, aber ich weiß, dass Sie die Optimierung von selbst durchsetzen können:

template <class T> 
typename boost::enable_if_t<boost::has_trivial_destructor<T>::value, void> 
wrap_uninitialized_copy (...) { 
    std::uninitialized_copy(...); 
} 

template <class T> 
typename boost::enable_if_t<!boost::has_trivial_destructor<T>::value, void> 
wrap_uninitialized_copy (...) { 
    try { 
     std::uninitialized_copy(...); 
    } catch(...) { 
     // some cleanup to do here... 
     throw; 
    } 
}