Sollte ich throw() bei der Implementierung von Non-Throwing-Swaps verwenden?

Question

Wenn ich das nicht-werfende Swap-Idiom implementiere, sollte ich throw() verwenden?

namespace A 
{ 
    struct B 
    { 
    void swap(B& other) throw() 
    { /* fancy stuff that doesn't throw */ } 
    }; 

    void swap(B& lhs, B& rhs) throw() 
    { lhs.swap(rhs); } 
} 

namespace std 
{ 
    template<> 
    void swap(A::B& lhs, A::B& rhs) throw() 
    { lhs.swap(rhs); } 
} 

Insbesondere Ich sorge mich um die throw() Spezifikation auf die Spezialisierung der std::swap setzen.

Bonus Frage:
Ist die Antwort anders, wenn C++ 0x noexcept Schlüsselwort verwendet?

Answer 1

In C++ 03 können Sie es dort setzen, aber wenn es wahr ist, dass die schicken Sachen nicht werfen, ist es im Grunde nur Dokumentation. Es kann sich auf die Leistung auswirken oder nicht, indem das Äquivalent von try/catch(...) { std::unexpected(); } um Aufrufe der Funktion hinzugefügt wird: Es hängt von der Implementierung ab, ob dies ohne Beeinträchtigung der Leistung möglich ist.

Wenn Sie planen, die noexceptOperator (5.3.7) in C++ 0x, dann mit Spezifikationen nicht werfen Ausnahme wert wird es plötzlich zu verwenden, so dass der Bediener die „richtige“ Antwort gibt. Ich weiß nicht wirklich, was der Operator noexcept ist, aber wenn es einen cleveren generischen Einsatz dafür gibt, zum Beispiel Algorithmen, die effizienter werden, wenn etwas nicht geworfen wird, dann wird es wohl notwendig sein, Funktionen als nicht zu markieren - um zu bekommen, was auch immer der Vorteil ist.

Zum Beispiel:

void foo() noexcept; 
void bar(); 

template <void(*FUNC)()> 
void generic_thing() { 
    if (noexcept(FUNC()) { 
     // this won't throw, perhaps we can somehow take advantage of that 
     FUNC(); 
    } else { 
     // this might throw 
     FUNC(); 
    } 
} 

Old style Ausnahme-Spezifikationen (dynamic-Ausnahme-Spezifikation) sind in C++ 0x veraltet (und sinnlos in C++ 03).

Answer 2

Realistisch, nein. Exception-Spezifikationen waren eine schöne Idee, aber die Realität von ihnen war, dass sie mehr als nur die Mehrheit des Codes behindert. Niemand benutzt sie und sie sind in C++ 0x veraltet. Verbringe keine Zeit damit, Ausnahmenspezifikationen in modernem C++ zu schreiben.

Answer 3

Es ist keine gute Idee, nein. Der Grund dafür ist, dass der Standard weiß, dass es manchmal unmöglich ist, die throw() Korrektheit zu erzwingen, die throw() für in erster Linie gebracht wurde. Insbesondere bei Vorlagen, bei denen je nach Instanziierung eine Ausnahme ausgelöst werden kann oder nicht, ist es ohne die Template-Instanziierung unmöglich, die Richtigkeit zu überprüfen. Der Standard erfordert daher nicht einmal Compiler, um den Ausnahmespezifizierer zu erzwingen; in der Tat verbietet es eine Implementierung von der Ablehnung eines Ausdrucks "nur weil, wenn es ausgeführt wird, wirft es oder könnte eine Ausnahme werfen, die die enthaltende Funktion nicht erlaubt" (15.4/11).

Wenn throw() keinen anderen Effekt als Dokumentation hat, sollte es auskommentiert werden; Auf diese Weise besteht zumindest keine Gefahr, den menschlichen Beobachter in die Irre zu führen.

Der Fall mit noexcept ist ganz anders. noexcept kommt aus einem anderen Grund; das der Leistung. Wenn Sie können garantieren, dass der Compiler keine Ausnahme ausgelöst wird, dann ermöglicht der Compiler selbst einige Optimierungen durchzuführen. Aber Sie müssen die Prüfungen selbst durchführen. Also, wenn in der Tat swap() nicht wirft (und es sollte nicht; das ist seine Existenzberechtigung) dann ist die Angabe noexcept eine gute Idee.