Ich kann mir keinen sinnvollen Move-Konstruktor vorstellen, der eine Exception wirft.

Wenn ich davon ausgehen könnte, hätte das viele Vorteile für mich. Einerseits wäre die Implementierung um einiges einfacher und ich könnte das Interface schöner gestalten (queue::pop() könnte eine rvalue auf das gepoppte Element zurückgeben).

Debug/Logging Output

Die Exception würde ich fangen und ignorieren. Es macht keinen Sinn, dass weiterzuleiten. Logging gehört eindeutig nicht zur Aufgabe des Movekonstruktors, auch weil Ort und Anzahl der Aufrufe ein Implementierungsdetail ist.

Kellerautomat schrieb:

Caches

Kellerautomat schrieb:

internem Locking.

Das andere Objekt ist tot und unbenutzt und das eigene ist neu. Da braucht es kein Locking.

Kellerautomat schrieb:

Darum gibt es auch std::move_if_noexcept.

Das gibt es wegen Alt-Code, der nur einen Kopierkonstruktor bereitstellt.

Wenn ich ein allgemeines Klassentemplate schreibe, ist es sinnvoll zu verlangen, dass der Move-Konstruktor noexcept ist?

Nein. Eher nicht.

muvvel schrieb:

Ich kann mir keinen sinnvollen Move-Konstruktor vorstellen, der eine Exception wirft.

Stell dir ein pair<T,U> vor, wo T move-optimiert ist, U aber nicht. Der Kopierkonstruktor von U schmeißt ggf eine Ausnahme. pair<T,U> wird dann einen potentiell ausnahmewerfenden Move-Konstruktor besitzen. Als Nutzer kannst du dir dann überlegen: Möchte ich starke Ausnahmesicherheit? Dann muss ich std::move_if_noexcept verwenden. Reicht mir die "basic guarantee"? Dann kann ich std::move verwenden und nehme damit in Kauf, dass bei einem fehlgeschlagenen Move die Originalinstanz ggf nicht mehr so aussieht, wie vorher.

std::vector fällt ähnlich auf das Kopieren beim Vergrößern des Vektors zurück, wenn seine Elemente nicht noexcept-movable sind aber dafür eine Kopierfunktion anbieten. Damit bietet z.B. push_back in solchen Fällen auch die starke Ausnahmesicherheit.

Stell dir ein pair<T,U> vor, wo T move-optimiert ist, U aber nicht. Der Kopierkonstruktor von U schmeißt ggf eine Ausnahme. pair<T,U> wird dann einen potentiell ausnahmewerfenden Move-Konstruktor besitzen.

Das ist Alt-Code. Da gehört U gefixt (und jede alte Klasse (die copyable ist) besitzt einen (implizit generierten) Move-Konstruktor, da musst du nicht ein exotisches Beispiel bringen).

krümelkacker schrieb:

Als Nutzer kannst du dir dann überlegen: Möchte ich starke Ausnahmesicherheit? Dann muss ich std::move_if_noexcept verwenden. Reicht mir die "basic guarantee"? Dann kann ich std::move verwenden und nehme damit in Kauf, dass bei einem fehlgeschlagenen Move die Originalinstanz ggf nicht mehr so aussieht, wie vorher.

Das Problem ist:

Exception Safety Affects a Class's Design

Ich müsste meine Klasse verpimpeln (mit dem PIMPL-Idiom versehen) um "strong guarantee" zu erreichen. std::move_if_noexcept alleine reicht leider nicht immer aus.

Auf der anderen Seite könnte ich meine Klasse auf Geschwindigkeit optimieren und trotzdem die strong guarantee bereitstellen, vorausgesetzt der Move-Konstruktor ist nothrow. Ist es das wert?

da musst du nicht ein exotisches Beispiel bringen).

Dass das "exotisches" sei, würde ich nicht behaupten. Es ist ein Beispiel aus den Veröffentlichungen des Komitees, Veröffentlichungen, die zur Einführung von noexcept und dazu geführt haben, ausnahmewerfende Move-Konstruktoren zu tolerieren. Wenn du eine Klasse aus teils move-optimierten Typen und teils "Legacy-Typen" baust, die keinen move-ctor haben abar dafür einen ausnahmewerfenden Konstruktor, dann ist ein ausnahmefreies Moven eben nicht möglich, es sei denn, du bringst die Legacy-Typen (die z.B. aus einer ganz anderen Bibliothek kommen) selbst auf den neusten Stand. Würde man throwing Move-Ctors einfach verbieten, dann würde man in einigen Fällen, nämlich in denen, wo man die starke Garantie nicht benötigt, Performance verschenken, da
alle "Elemente" kopiert werden müssten, obwohl einige davon vielleicht move-bar sind. So, wie es jetzt ist, ist es doch am besten. Kein nothrow-move-Zwang, aber dafür kann man den nothrow-Status per type_traits abfragen und ggf auf Kopieren zurückfallen, wenn man die strong guarantee braucht.

muvvel schrieb:

Ist es das wert?

Das kannst nur Du bewerten, solange du nicht konkreter wirst.