Wann kann kein Compiler RVO oder NRVO verwenden?

Question

Move-Semantik kann nützlich sein, wenn der Compiler RVO und NRVO nicht verwenden kann. Aber in welchem ​​Fall kann der Compiler diese Funktionen nicht verwenden?

Answer 1

Die Antwort ist, dass es Compiler und Situation abhängig ist. Z.B. Kontrollflussverzweigungen könnten Optimierer verwirren. Wikipedia dieses Beispiel:

#include <string> 
std::string f(bool cond = false) { 
    std::string first("first"); 
    std::string second("second"); 
    // the function may return one of two named objects 
    // depending on its argument. RVO might not be applied 
    return cond ? first : second; 
} 

int main() { 
    std::string result = f(); 
} 

Answer 2

Nun, es ist nicht so sehr, ob der Compiler RVO verwenden kann, sondern ob er dadurch eine Kopierkonstruktion vermeiden kann.

Bedenken Sie:

struct Blah 
{ 
    int x; 
    Blah(int const _x): x(_x) { cout << "Hum de dum " << x << endl; } 
}; 

Blah foo() 
{ 
    Blah const a(1); 
    if(fermatWasRight()) { return Blah(2); } 
    return a; 
} 

die Nebenwirkungen Erste (Ausgabe von dem Konstruktor) Hier ist auf den ersten Blick ziemlich unvereinbar mit a directy in Speicher vom Anrufer zur Verfügung gestellt zu konstruieren. Wenn der Compiler jedoch intelligent genug ist, kann er feststellen, dass das Zerstören dieses Objekts eine Nulloperation ist. Und ganz allgemein, für jede spezielle Situation, wenn der Compiler schlau genug ist, kann er es vielleicht schaffen, eine Kopieroperation zu vermeiden, egal wie hinterhältig wir den Code entwerfen.

Ich bin nicht sicher über die formale obwohl, aber die oben genannten, mit mehr Nutzlast im Objekt, so dass das Kopieren teurer wäre, ist ein Fall, in dem Bewegung Semantik helfen kann, so dass die Optimierung garantiert wird, egal Smart des Compilers (oder nicht).