Ist der pass-by-value-and-dann-bewegen konstruieren eine schlechte Redewendung?

Aber was passiert, wenn a ist ein lvalue? Es scheint, es wird eine Kopie
Bau und dann ein move-Zuweisung (unter der Annahme Einer hat eine richtige verschieben
Zuweisungsoperator). Verschieben von Aufgaben kann teuer werden, wenn das Objekt
zu viele member-Variablen.

Problem gut erkannt. Ich würde nicht so weit gehen, zu sagen, dass die pass-by-value-and-dann-bewegen konstruieren ist ein schlechter idiom, aber es hat definitiv seine Tücken lauern.

Wenn das Ihre Art ist teuer, zu verschieben und /oder verschieben ist im Grunde nur eine Kopie, dann die pass-by-value-Ansatz ist suboptimal. Beispiele für solche Arten umfassen würde, die Typen mit fester Größe array als member: kann Es relativ teuer, sich zu bewegen und eine Bewegung ist nur eine Kopie. Siehe auch

• Kleine String-Optimierung und Move-Operationen und
• "Wollen Geschwindigkeit? Messen." (von Howard Hinnant)

in diesem Zusammenhang.

Den pass-by-value-Ansatz hat den Vorteil, dass Sie nur halten müssen, um eine Funktion, sondern Sie zahlen dafür mit Leistung. Es kommt auf deine Anwendung an, ob diese Pflege Vorteil überwiegt den Verlust in der Leistung.

Der pass von lvalue und rvalue reference-Ansatz kann dazu führen, Wartung Kopfschmerzen schnell, wenn Sie mehrere Argumente. Bedenken Sie:

#include <vector>
using namespace std;

struct A { vector<int> v; };
struct B { vector<int> v; };

struct C {
  A a;
  B b;
  C(const A&  a, const B&  b) : a(a), b(b) { }
  C(const A&  a,       B&& b) : a(a), b(move(b)) { }
  C(      A&& a, const B&  b) : a(move(a)), b(b) { }
  C(      A&& a,       B&& b) : a(move(a)), b(move(b)) { }  
};

Wenn Sie mehrere Argumente, haben Sie eine permutation problem. In diesem sehr einfachen Beispiel, es ist wohl doch nicht so schlecht zu halten, die diese 4 Konstruktoren. Aber schon in diesem einfachen Fall würde ich ernsthaft erwägen, mit dem pass-by-value-Ansatz mit einer einzigen Funktion

C(A a, B b) : a(move(a)), b(move(b)) { }

anstelle der oben genannten 4 Konstruktoren.

Also lange Geschichte kurz, weder Ansatz ist ohne Nachteile. Treffen Sie Ihre Entscheidungen auf der Grundlage der tatsächlichen profiling-Informationen, anstatt die Optimierung vorzeitig.

Aktuelle Antworten sind Recht unvollständig. Stattdessen werde ich versuchen zu dem Schluss, basierend auf den Listen der vor-und Nachteile finde ich.

Kurze Antwort

Kurz gesagt, es kann OK sein, manchmal aber auch schlecht.

Dieses idiom, nämlich Vereinheitlichung - Schnittstelle, hat eine bessere Klarheit (sowohl in der Konzeption und Umsetzung) im Vergleich zur Weiterleitung von Vorlagen oder anderen überlastungen. Es wird manchmal mit copy-and-swap (tatsächlich, sowie verschieben und swap - in diesem Fall).

Detaillierte Analyse

Die Profis sind:

• Es muss nur eine Funktion für jeden parameter-Liste.
  • Es muss ja nur einer, nicht mehrere gewöhnliche überlastungen (oder sogar 2ⁿ überladungen, wenn Sie n Parameter, wenn jeder kann von unqualifizierten oder const-qualifizierten).
  • Wie innerhalb einer forwarding template-Parameter durch Wert übergeben sind kompatibel mit nicht nur const, aber volatile, die noch weiter verringern gewöhnliche überlastungen.
    • Kombiniert mit der Kugel oben, brauchen Sie nicht 4ⁿ überlastungen zu dienen {unqulified, const, const, const volatile} Kombinationen für n Parameter.
  • Im Vergleich zu einer Weiterleitung Vorlage, es kann eine nicht-Vorlagen-Funktion, solange die Parameter sind nicht nötig, um generische (parametrisierte durch Vorlage Typ-Parameter). Dies ermöglicht out-of-line-Definitionen eher als template-Definitionen, die benötigt werden, instanziiert für jede Instanz in jeder übersetzungseinheit, die signifikante Verbesserung des translation-Zeit-Leistung (in der Regel, sowohl während der Kompilierung und linking).
  • Es macht auch andere überlastungen (wenn überhaupt) einfacher zu implementieren.
    • Wenn Sie eine Weiterleitung Vorlage für einen parameter Objekttyp T kann es immer noch clash mit überladungen mit einem parameter const T& in der gleichen position, denn das argument kann ein lvalue des Typs T und die Schablone instantiiert mit Typ - T& (statt const T&) denn es ist mehr bevorzugt, die durch die überlastung Regel, wenn es keine andere Möglichkeit gibt zu unterscheiden, welche ist die beste überlastung Kandidaten. Diese Inkonsistenz kann ganz überraschend.
    • Insbesondere der Auffassung, Sie habe die Weiterleitung template-Konstruktor mit einem parameter vom Typ P&& eine Klasse C. Wie viele Zeit werden Sie vergessen, ausgeschlossen die Instanz von P&& Weg von möglicherweise cv-qualifiziert C von SFINAE (z.B. durch hinzufügen typename = enable_if_t<!is_same<C, decay_t<P>> zu den template-parameter-Liste), um sicherzustellen, dass es keinen Zusammenstoß mit der copy/move-Konstruktoren (auch wenn letztere werden explizit vom Benutzer bereitgestellt)?
• Da die parameter durch Wert übergeben wird, ein nicht-Referenz-Typ, Sie können erzwingen, dass das argument übergeben werden, als prvalue. Dies kann einen Unterschied machen, wenn das argument von einem Klasse literal-Typ. Betrachten Sie es wie eine Klasse mit einer statischen constexpr Daten-member deklariert, die in einer Klasse ohne ein out-of-class-definition, wenn es verwendet wird, als argument für einen parameter der lvalue-Referenz-Typ kann es schließlich nicht verlinken, weil es ist OS-verwendet und es gibt keine definition.
  • Hinweis: da die ISO-C++ 17 die Regeln der statischen constexpr Datenelement geändert haben die Einführung einer definition implizit, so ist der Unterschied nicht signifikant ist in diesem Fall.

Die Nachteile sind:

• Eine vereinheitlichende Schnittstelle kann nicht ersetzen, kopieren und verschieben von Konstruktoren, wo der parameter Objekttyp ist identisch mit der Klasse. Ansonsten copy-Initialisierung der parameter wäre eine unendliche Rekursion, denn es ruft das übergeordnete Konstruktor, und dann wird es sich selbst aufrufen.
• Wie bereits von anderen beantwortet, wenn die Kosten für die Kopie ist nicht vernachlässigbar (Billig und vorhersehbar genug ist), bedeutet dies, dass Sie fast immer haben die degeneration der Leistung und der Anrufe, wenn die Kopie nicht notwendig, da copy-Initialisierung einer Vereinheitlichung passed-by-value-parameter bedingungslos Einführung einer kopieren (entweder kopiert oder verschoben-zu) mit dem argument, es sei denn erstellte.
  • Auch mit obligatorische Auslassung, da C++17, copy-Initialisierung eines parameter-Objekts ist kaum noch frei zu sein, entfernt - es sei denn, die Umsetzung versuchen sehr schwer zu beweisen das Verhalten nicht geändert nach als-ob-Regeln statt der gewidmet copy elision Regeln hier anwendbar, was vielleicht manchmal unmöglich, ohne eine ganze Programm-Analyse.
  • Ebenfalls, die Kosten der Zerstörung sind möglicherweise nicht vernachlässigbar, insbesondere wenn nicht-triviale Teilobjekte berücksichtigt werden (z.B. in Fällen von Containern). Der Unterschied ist, dass es nicht nur angewendet, um die copy-Initialisierung eingeführt durch das kopieren der Konstruktion, sondern auch durch die Bewegung der Konstruktion. Machen bewegen billiger als Kopie in Konstruktoren können nicht zur Verbesserung der situation. Die mehr Kosten von copy-Initialisierung, die mehr Kosten für die Zerstörung, die Sie haben, zu leisten.
• Ein kleine Manko ist, dass es keine Möglichkeit zur Einstellung der Schnittstelle auf unterschiedliche Weise, wie plural überlastungen, zum Beispiel, wenn Sie unterschiedliche noexcept-Bezeichner für die Parameter der const& und && qualifizierten Typen.
  • OTOH, in diesem Beispiel, die Vereinheitlichung der Schnittstelle wird in der Regel bieten Sie mit noexcept(false) copy + noexcept bewegen, wenn Sie gibt noexcept oder immer noexcept(false) wenn Sie angeben, dass nichts (oder explizite noexcept(false)). (Hinweis: im ersten Fall noexcept nicht verhindern, dass das werfen beim kopieren, denn das wird nur auftreten, während der Auswertung von Argumenten, die aus der Funktion Körper.) Es gibt keine weitere chance, optimieren Sie Sie separat.
  • Dieser wird als geringfügig eingestuft, weil es nicht Häufig benötigt in der Realität.
  • Auch wenn solche überladungen verwendet werden, sind Sie wahrscheinlich verwirrend durch die Natur: die verschiedenen Planern verstecken können subtile, aber wichtige Verhaltens-Unterschiede, die schwierig zu Grunde geht. Warum nicht unterschiedliche Namen anstelle von überlastungen?
  • Hinweis: das Beispiel von noexcept werden können, besonders problematisch, da C++17, weil noexcept-Spezifikation nun auf die Funktion geben. (Einige unerwartete Kompatibilitätsprobleme können diagnostiziert werden, durch Clang++ Warnung.)

Manchmal die bedingungslose Kopie ist tatsächlich nützlich. Da die Komposition von Operationen mit starken Ausnahme-Garantie nicht über die Garantie in der Natur, eine Kopie kann verwendet werden, als eine transnationale, Staatliche Halter, wenn der starke-Ausnahme-Garantie ist erforderlich und der Vorgang kann nicht zerbrochen werden, als Folge von Operationen mit nicht weniger strenge (nicht-Ausnahme oder stark) Ausnahme-Garantie. (Dies beinhaltet die copy-and-swap-idiom, obwohl die Zuordnungen sind nicht empfohlen vereint zu sein für andere Gründe, im Allgemeinen, siehe unten.) Jedoch, dies bedeutet nicht das kopieren auf andere Weise inakzeptabel ist. Wenn die Absicht, die Schnittstelle ist immer zu erstellen, die ein Objekt vom Typ T, und die Kosten der Verlagerung T ist vernachlässigbar, die Kopie kann verschoben werden, um das Ziel ohne unerwünschte overhead.

Schlussfolgerungen

Also für einige bestimmten Operationen, hier sind Vorschläge, ob mit einer Vereinheitlichung der Schnittstelle zu ersetzen:

1. Wenn nicht alle parameter-Typen entsprechen den einheitlichen Schnittstelle, oder wenn es einen Unterschied im Verhalten anderen, als die Kosten für neue Kopien zu Operationen Einheit, es kann nicht sein, eine verbindende Schnittstelle.
2. Wenn die folgenden Bedingungen sind nicht fit für alle Parameter, es kann nicht sein, eine verbindende Schnittstelle. (Aber es kann noch unterteilt werden anders benannt-Funktionen, das delegieren von einem Anruf zum anderen.)
3. Für einen parameter vom Typ T, wenn Sie eine Kopie jedes argument wird benötigt für alle Operationen verwenden Vereinheitlichung.
4. Wenn beide kopieren und verschieben von Bau T haben ignorable Kosten, nutzen vereinen.
5. Wenn die Absicht, die Schnittstelle ist immer zu erstellen, die ein Objekt vom Typ T, und die Kosten für den Umzug Bau T ist vernachlässigbar, verwenden Vereinheitlichung.
6. Sonst, vermeiden vereinen.

Hier sind einige Beispiele, die Notwendigkeit zu vermeiden, Vereinheitlichung:

1. Zuordnung von Operationen (einschließlich der Zuordnung zu den teilobjekten davon, in der Regel mit copy-and-swap-idiom) für T ohne vernachlässigbar Kosten, die in kopieren und verschieben Konstruktionen erfüllt nicht die Kriterien für die Vereinheitlichung, weil die intention des Auftrags ist nicht zu erstellen (aber ersetzen den Inhalt) des Objekts. Das kopierte Objekt wird irgendwann zerstört werden, das verursacht unnötigen Aufwand. Dies wird noch deutlicher, für Fälle der selbst-Zuordnung.
2. Einfügen der Werte in einem container die Kriterien nicht erfüllt, es sei denn, die copy-Initialisierung und Zerstörung vernachlässigbar Kosten. Wenn der Vorgang fehlschlägt (durch die Zuteilung Versagen, doppelte Werte oder so) nach copy-Initialisierung die Parameter werden zerstört, das verursacht unnötigen Aufwand.
3. Bedingt Erstellung des Objekts basierend auf Parametern, wird der Aufwand, wenn es eigentlich nicht das Objekt erstellen (z.B. std::map::insert_or_assign-wie container einfügen, auch trotz der Fehler oben).

Hinweis: die genaue Grenze des "ignorable" Kosten ist etwas subjektiv, weil es letztendlich davon abhängt, wie viel Kosten toleriert werden können, von den Entwicklern und/oder den Benutzer, und es kann variieren von Fall zu Fall.

Praktisch, ich (konservativ) übernimmt keinerlei trivial kopierbar und trivailly zerstörbare-Typ, dessen Größe nicht mehr als eine Maschine-Wort (wie ein Zeiger) Qualifikation, die Kriterien der ignorable Kosten in der Regel - wenn der resultierende code tatsächlich zu viel Kosten, in diesem Fall schlägt es vor, entweder eine falsche Konfiguration des build-tool verwendet wird, oder die toolchain ist nicht bereit für die Produktion.

Tun Profil, wenn es keine weiteren Zweifel an der Leistung.

Zusätzliche Fallstudie

Gibt es einige andere bekannte Arten bevorzugt werden übergeben von Werten konventionell:

• STL-Stil generischen code direkt kopieren von Parametern. Es kann auch ohne std::move, weil die Kosten für die kopieren wird angenommen, vernachlässigbar und ein Umzug nicht unbedingt machen es besser. Solche Parameter umfassen Iteratoren und Funktions-Objekte (ausser im Falle von (argument) die Weiterleitung der Anrufer-Wrapper).
• - Typen vermutlich mit den Kosten vergleichbar mit " pass-by-value-parameter-Typen mit ignorable Kosten sind auch am günstigsten gelegene pass-by-value. (Manchmal sind Sie als engagierte alternativen.) Zum Beispiel Instanzen von std::initializer_list und std::basic_string_view sind mehr oder weniger zwei Zeiger oder einen Zeiger oder plus Größe. Diese Tatsache macht Sie Billig genug, um direkt übergeben, ohne Referenzen.

Ebenso einige Typen sollten vermeiden Weitergabe von Werten, es sei denn, Sie benötigen eine Kopie. Container sind typische Beispiele in dieser Art.
* Insbesondere Zuweisung-awared Container und einige andere Arten mit ähnlichen Behandlung zu allocators ("container-Semantik", in David Krauss' Wort), sollte nicht per value übergeben werden, auch wenn die Leistung ist völlig uninteressiert - Zuweisung Vermehrung ist nur ein weiterer großer semantischer Wurm.

Ein paar andere Arten, die konventionell hängt. Zum Beispiel, sehen Sie GotW #91 für shared_ptr Instanzen. (Allerdings nicht alle smart-Pointer sind so; observer_ptr mehr wie ein raw-Pointer.)

Ich beantworte mich selbst, denn ich werde versuchen, das zusammenzufassen, einige der Antworten. Wie viele Züge/Kopien haben wir in jedem Fall?

(A) Pass-by-value und bewegen Zuordnung konstruieren, vorbei an einem X-parameter. Wenn X eine...

Vorübergehend: 1 bewegen Sie (die Kopie erstellte)

Lvalue: 1 kopieren 1 bewegen

std::move(lvalue): 2 bewegt

(B) übergabe per Referenz und Kopie Zuweisung üblichen (vor C++11) zu konstruieren. Wenn X eine...

Vorübergehend: 1 Kopie

Lvalue: 1 Kopie

std::move(lvalue): 1-Kopie

Können wir davon ausgehen, die drei Arten von Parametern sind gleich wahrscheinlich. So alle 3 Anrufe, die wir haben (A) mit 4 Zügen und 1 Kopie, oder (B) 3 Exemplare. I. e., im Durchschnitt, (A) 1.33 bewegt und 0,33 Kopien pro Anruf oder (B) 1 Kopie pro Aufruf.

Wenn wir kommen, um eine situation, bei der unsere Klassen bestehen meist aus Hülsen, Züge sind so teuer wie Kopien. So hätten wir 1.66 kopiert (oder verschiebt) pro Aufruf der setter-im Fall (A) und 1-Kopien im Fall (B).

Können wir sagen, dass in einigen Fällen ("PODs" Basis-Typen), die pass-by-value-and-dann-bewegen konstruieren, ist eine sehr schlechte Idee. Es ist 66% langsamer und es hängt ein C++11 feature.

Auf der anderen Seite, wenn unsere Klassen umfassen Container (die Verwendung von dynamischen Speicher), (A) soll deutlich schneller sein (außer wenn wir meistens pass lvalues).

Bitte, korrigieren Sie mich, wenn ich falsch bin.