¿Cuándo un compilador no puede usar RVO o NRVO?

Question

La semántica de movimiento puede ser útil cuando el compilador no puede usar RVO y NRVO. ¿Pero en qué caso el compilador no puede usar estas características?

Answer 1

La respuesta es que depende del compilador y de la situación. P.ej. la ramificación del flujo de control puede confundir a los optimizadores. Wikipedia dar este ejemplo:

#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

Bueno, no se trata tanto de si el compilador puede usar RVO, sino de si puede evitar la construcción de una copia.

considerar:

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; 
} 

Obtención de los efectos secundarios (salida desde el constructor) aquí, es a primera vista bastante incompatible con la construcción de a o directamente en el almacenamiento proporcionado por la persona que llama. Pero si el compilador es lo suficientemente inteligente, puede notar que la destrucción de este objeto es una operación nula. Y, en términos más generales, para cualquier situación en particular, si el compilador es lo suficientemente inteligente, tal vez pueda evitar una operación de copia, sin importar qué tan furtivamente diseñemos el código.

No estoy seguro de lo formal, pero lo anterior, con más carga en el objeto para que la copia sea más costosa, es un caso donde la semántica de movimiento puede ayudar, de modo que la optimización estará garantizada sin importar el inteligencia del compilador (o no).