¿Se puede usar unique_ptr de forma segura en las colecciones stl?

Question

Estoy confundido con la filosofía unique_ptr y rvalue move.

Digamos que tenemos dos colecciones:

std::vector<std::auto_ptr<int>> autoCollection; 
std::vector<std::unique_ptr<int>> uniqueCollection; 

Ahora que se puede esperar el siguiente al fracaso, ya que no se sabe lo que el algoritmo está haciendo internamente y tal vez la realización de copias de articulación interna y similares, arrancando por lo tanto propiedad de distancia de auto_ptr:

std::sort(autoCollection.begin(), autoCollection.end()); 

Entiendo esto. Y el compilador con razón no permite que esto suceda.

Pero entonces hacer esto:

std::sort(uniqueCollection.begin(), uniqueCollection.end()); 

Y esto compila. Y no entiendo por qué. No creo que se puedan copiar unique_ptrs. ¿Esto significa que no se puede tomar un valor de pivote, por lo que el tipo es menos eficiente? ¿O es este pivote en realidad un movimiento, que de hecho es tan peligroso como la colección de auto_ptrs, y el compilador no debería permitirlo?

Creo que me falta algo crucial de información, así que espero ansiosamente que alguien me proporcione el aha! momento.

Answer 1

creo que es más una cuestión de la filosofía de la técnica :)

La pregunta de fondo es ¿cuál es la diferencia entre Mover y copiar. No voy a saltar en el lenguaje/standardista técnica, vamos a hacer de manera simple:

• Copia: crear otro objeto idéntico (o, al menos, una que debe comparar iguales)
• Mover: tomar un objeto y ponerlo en otra ubicación

Como dijiste, es posible implementar Mover en el plazo de la copia: crea una copia en la nueva ubicación y descarta el original. Sin embargo, hay dos problemas allí. Uno es de rendimiento, el segundo es sobre los objetos utilizados para RAII: ¿cuál de los dos debe tener la propiedad?

Un constructor Mover adecuada resuelve los 2 números:

• Está claro qué objeto tiene la propiedad: la nueva, ya que se descartará el original
• lo tanto, es necesario copiar los recursos señalaron , lo que permite una mayor eficiencia

El auto_ptr y unique_ptr son un muy buen ejemplo de esto.

Con un auto_ptr tiene una copia semántica atornillada: el original y la copia no son iguales.Podría usarlo para su semántica de movimiento, pero existe el riesgo de que pierda el objeto apuntado a alguna parte.

Por otro lado, el unique_ptr es exactamente eso: garantiza un propietario único del recurso, evitando así la copia y el inevitable problema de eliminación que seguiría. Y la no copia también está garantizada en tiempo de compilación. Por lo tanto, es adecuado en contenedores siempre que no intente tener inicialización de copia.

typedef std::unique_ptr<int> unique_t; 
typedef std::vector<unique_t> vector_t; 

vector_t vec1;       // fine 
vector_t vec2(5, unique_t(new Foo));  // Error (Copy) 
vector_t vec3(vec1.begin(), vec1.end()); // Error (Copy) 
vector_t vec3(make_move_iterator(vec1.begin()), make_move_iterator(vec1.end())); 
    // Courtesy of sehe 

std::sort(vec1.begin(), vec1.end()); // fine, because using Move Assignment Operator 

std::copy(vec1.begin(), vec1.end(), std::back_inserter(vec2)); // Error (copy) 

Así que puede usarunique_ptr en un recipiente (a diferencia de auto_ptr), pero una serie de operaciones será imposible porque implican la copia, que el tipo no es compatible.

Desafortunadamente Visual Studio puede ser bastante laxo en la aplicación del estándar y también tiene una serie de extensiones que necesitaría deshabilitar para garantizar la portabilidad del código ... no lo use para verificar el estándar :)

Answer 2

Las unique_ptr s se están moviendo utilizando su constructor de movimiento. unique_ptr es movible, pero no CopyConstructable.

Hay un gran artículo sobre las referencias rvalue here. Si aún no ha leído sobre ellos, o está confundido, ¡eche un vistazo!

Answer 3

std::sort podría funcionar solo con operaciones de movimiento y sin copia, siempre que haya una sola copia activa de cada objeto en un momento dado. Este es un requisito más débil que trabajar en el lugar, ya que en principio se puede asignar otra matriz temporalmente y mover todos los objetos para reordenarlos.

por ejemplo con std::vector<std::unique_ptr<T>> que excede su capacidad, asigna almacenamiento para un vector más grande y luego mueve todos los objetos del almacenamiento anterior al nuevo. Esta no es una operación local, pero es perfectamente válida.

Pues resulta que, como algoritmos de ordenación rápida-tipo y el montón-tipo puede en el trabajo hecho en el lugar sin dificultad. La rutina de partición quick-sort usa std :: swap internamente, que cuenta como una operación de movimiento para ambos objetos involucrados. Al seleccionar un pivote, un truco es intercambiarlo con el primer elemento en el rango, de esta manera nunca se moverá hasta que se termine la partición.