La devolución de unique_ptr de las funciones

Question

unique_ptr<T> no permite la construcción de copias, en cambio admite la semántica de movimientos. Sin embargo, puedo devolver un unique_ptr<T> desde una función y asignar el valor devuelto a una variable.

#include <iostream> 
#include <memory> 

using namespace std; 

unique_ptr<int> foo() 
{ 
    unique_ptr<int> p(new int(10)); 

    return p;     // 1 
    //return move(p);   // 2 
} 

int main() 
{ 
    unique_ptr<int> p = foo(); 

    cout << *p << endl; 
    return 0; 
} 

El código anterior compila y funciona según lo previsto. Entonces, ¿cómo es que la línea 1 no invoca el constructor de copia y da como resultado errores de compilación? Si tuviera que usar la línea 2, tendría sentido (usar la línea 2 también funciona, pero no estamos obligados a hacerlo).

Sé que C++ 0x permite esta excepción a unique_ptr ya que el valor de retorno es un objeto temporal que se destruirá tan pronto como la función salga, garantizando así la singularidad del puntero devuelto. Tengo curiosidad acerca de cómo se implementa esto, ¿está incluido en el compilador especial o hay alguna otra cláusula en la especificación del lenguaje que explote?

Answer 1

hay alguna otra cláusula en la especificación del lenguaje que este explota?

Sí, ver 12.8 §34 y §35:

Cuando se cumplen ciertos criterios, se permite que una aplicación para omitir la construcción copiar/mover de un objeto de clase [...] Este elisión de las operaciones de copiar/mover, llamado copia elisión, se permite [...] en una instrucción de retorno de una función con un tipo de retorno de clase, cuando la expresión es el nombre de un objeto automática no volátil con el mismo tipo cv no calificado como el tipo de retorno de función [...]

Cuando se cumplen los criterios para la elisión de una operación de copia y el objeto que se va a copiar se designa por un lvalue, resolución de sobrecarga para seleccionar el constructor para la copia se realiza primero como si el objeto se designaron por un rvalue.

---

sólo quería añadir un punto más que el retorno por valor debería ser la opción por defecto aquí porque un valor indicada en la sentencia de retorno en el peor de los casos, es decir, sin elisiones en C++ 11, C + +14 y C++ 17 se tratan como un valor r. Así, por ejemplo, la función siguiente se compila con la bandera -fno-elide-constructors

std::unique_ptr<int> get_unique() { 
    auto ptr = std::unique_ptr<int>{new int{2}}; // <- 1 
    return ptr; // <- 2, moved into the to be returned unique_ptr 
} 

... 

auto int_uptr = get_unique(); // <- 3 

Con el indicador en la compilación hay dos movimientos (1 y 2) pasando en esta función y luego un movimiento más adelante (3).

Answer 2

Esto no es de ninguna manera específico para unique_ptr, pero se aplica a cualquier clase que sea movible. Está garantizado por las reglas de idioma ya que regresas por valor. El compilador intenta eludir copias, invoca un constructor de movimiento si no puede eliminar copias, llama a un constructor de copia si no se puede mover y no puede compilar si no puede copiar.

Si tiene una función que acepta unique_ptr como argumento, no podrá pasarle p. Debería invocar explícitamente el constructor de movimientos, pero en este caso no debería usar la variable p después de la llamada a bar().

void bar(std::unique_ptr<int> p) 
{ 
} 

int main() 
{ 
    unique_ptr<int> p = foo(); 
    bar(p); // error, can't implicitly invoke move constructor on lvalue 
    bar(std::move(p)); // OK but don't use p afterwards 
} 

Answer 3

unique_ptr no tiene el constructor de copia tradicional. En cambio, tiene un "movimiento constructor" que utiliza referencias rvalue:

unique_ptr::unique_ptr(unique_ptr && src); 

Una referencia rvalue (el doble ampersand) solamente se unirá a una rvalue. Es por eso que obtienes un error cuando tratas de pasar un lvalue unique_ptr a una función. Por otro lado, un valor que se devuelve de una función se trata como un valor r, por lo que el constructor de movimiento se llama automáticamente.

Por cierto, esto funciona correctamente:

bar(unique_ptr<int>(new int(44)); 

El unique_ptr temporal aquí es un valor de lado derecho.

Answer 4

Una cosa que no me veo en otras respuestas es Para aclarar another answers que hay una diferencia entre volver std :: unique_ptr que se ha creado dentro de una función, y uno que se ha dado a esa función.

El ejemplo podría ser así:

class Test 
{int i;}; 
std::unique_ptr<Test> foo1() 
{ 
    std::unique_ptr<Test> res(new Test); 
    return res; 
} 
std::unique_ptr<Test> foo2(std::unique_ptr<Test>&& t) 
{ 
    // return t; // this will produce an error! 
    return std::move(t); 
} 

//... 
auto test1=foo1(); 
auto test2=foo2(std::unique_ptr<Test>(new Test)); 

Answer 5

Creo que es perfectamente explicado en el punto 25 de Scott Meyers' Effective Modern C++. He aquí un extracto:

La parte de la Norma bendiciendo el RVO va a decir que si se cumplen las condiciones para la RVO, pero los compiladores elegir no realizar la elisión copia, siendo devuelto debe ser tratado como un objeto rvalue En efecto, el Estándar requiere que cuando se permita el RVO, se lleve a cabo una elisión de copia o std::move se aplique implícitamente a los objetos locales que se devuelvan.

Aquí, RVO se refiere a retorno optimización valor y si las condiciones para la RVO se cumplen medios de retorno del objeto local declarada dentro de la función que se puede esperar para hacer el RVO, que también se explica muy bien en el ítem 25 de su libro al referirse al estándar (aquí el objeto local incluye los objetos temporales creados por la declaración de devolución). La mayor extracción del extracto es , ya sea que se realice una elisión de copia o std::move en objetos locales que se devuelven. Scott menciona en el ítem 25 que std::move se aplica implícitamente cuando el compilador elige no eludir la copia y el programador no debe hacerlo explícitamente.

En su caso, el código es claramente un candidato para RVO ya que devuelve el objeto local p y el tipo de p es el mismo que el tipo de retorno, lo que resulta en la copia elisión. Y si el compilador decide no eludir la copia, por cualquier razón, std::move hubiera pateado la línea 1.