expliziter Copykonstruktor oder implizite Parameter von Wert

Question

ich kürzlich gelesen (und leider vergessen, wo), dass der beste Weg Operator zu schreiben = ist wie folgt:

foo &operator=(foo other) 
{ 
    swap(*this, other); 
    return *this; 
} 

statt dem:

foo &operator=(const foo &other) 
{ 
    foo copy(other); 
    swap(*this, copy); 
    return *this; 
} 

Die Idee ist, dass, wenn Operator = mit einem Rvalue aufgerufen wird, die erste Version die Konstruktion einer Kopie optimieren kann. Wenn also mit einem rvalue aufgerufen wird, ist die erste Version schneller und wenn sie mit einem lvalue aufgerufen wird, sind die beiden gleichwertig.

Ich bin neugierig, was andere Leute darüber denken? Würden die Leute die erste Version wegen mangelnder Deutlichkeit meiden? Habe ich Recht, dass die erste Version besser sein kann und niemals schlechter sein kann?

Answer 1

Sie lesen vermutlich aus: http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/

Ich habe nicht viel zu sagen, da ich die Verbindung denke, die Gründe ziemlich gut erklärt. Anekdotisch kann ich bestätigen, dass die erste Form in meinen Builds mit MSVC weniger Kopien ergibt, was sinnvoll ist, da Compiler möglicherweise nicht in der Lage sind, Kopien auf dem zweiten Formular zu machen. Ich stimme zu, dass die erste Form eine strenge Verbesserung ist und niemals schlechter als die zweite ist.

Edit: Die erste Form könnte ein bisschen weniger idiomatisch sein, aber ich denke nicht, dass es viel weniger klar ist. (IMO, es ist nicht mehr überraschend, als die Copy-and-Swap-Implementierung des Zuweisungsoperators zum ersten Mal zu sehen.)

Edit # 2: Ups, ich meinte, Kopier-Elision, nicht RVO zu schreiben.

Answer 2

denke ich, dass Sie den Unterschied zwischen könnte verwirrend sein:

foo &operator=(const foo &other); und
const foo &operator=(const foo &other);

Die erste Form verwendet werden soll, ermöglichen: (a = b) = c;

Answer 3

Diese beiden sind eigentlich die gleichen. Der einzige Unterschied ist, wo Sie in einem Debugger auf "Step In" drücken. Und Sie sollten im Voraus wissen, wo es zu tun ist.

Answer 4

Ich bevorzuge in der Regel die zweite aus Lesbarkeit und 'am wenigsten Überraschung' Sicht jedoch anerkenne ich, dass die erste effizienter sein kann, wenn der Parameter ein temporärer ist.

Die erste kann wirklich zu keine Kopien führen, nicht nur die einzelne Kopie und es ist denkbar, dass dies ein echtes Problem in extremen Situationen sein kann.

z. Nimm dieses Testprogramm. gcc -O3 -S (GCC-Version 4.4.2 20091222 (Red Hat 4.4.2-20) (GCC)) generiert einen Aufruf von Bs Kopierkonstruktor, aber keine Aufrufe von A's Kopierkonstruktor für die Funktion f (der Zuweisungsoperator ist sowohl für A als auch für B inline)). A und B können beide als sehr einfache String-Klassen angesehen werden. Die Zuweisung und das Kopieren für data würde in den Konstruktoren und der Zuordnung in dem Destruktor auftreten.

#include <algorithm> 

class A 
{ 
public: 
    explicit A(const char*); 
    A& operator=(A val)  { swap(val); return *this; } 
    void swap(A& other)  { std::swap(data, other.data); } 
    A(const A&); 
    ~A(); 

private: 
    const char* data; 
}; 

class B 
{ 
public: 
    explicit B(const char*); 
    B& operator=(const B& val) { B tmp(val); swap(tmp); return *this; } 
    void swap(B& other)   { std::swap(data, other.data); } 
    B(const B&); 
    ~B(); 

private: 
    const char* data; 
}; 

void f(A& a, B& b) 
{ 
    a = A("Hello"); 
    b = B("World"); 
} 

Answer 5

diese wie diese es einfacher für einen Compiler könnte

foo bar; 
bar = f(); 

foo &foo::operator=(foo other) {/*...*/ return *this;} 
foo f(); 

in Code Aufgrund der Aufruf des Kopierkonstruktors zu beseitigen. Mit RVO könnte es die Adresse des Operators other Parameter als die Stelle für f() verwenden, um seinen Rückgabewert bei zu konstruieren.

Es scheint, dass diese Optimierung auch für den zweiten Fall möglich ist, obwohl ich glaube, dass es schwieriger sein könnte. (Besonders wenn der Bediener nicht inline ist.)