¿Debo std :: mover un shared_ptr en un constructor de movimiento?

Question

considerar:

#include <cstdlib> 
#include <memory> 
#include <string> 
#include <vector> 
#include <algorithm> 
#include <iterator> 
using namespace std; 

class Gizmo 
{ 
public: 
    Gizmo() : foo_(shared_ptr<string>(new string("bar"))) {}; 
    Gizmo(Gizmo&& rhs); // Implemented Below 

private: 
    shared_ptr<string> foo_; 
}; 

/* 
// doesn't use std::move 
Gizmo::Gizmo(Gizmo&& rhs) 
: foo_(rhs.foo_) 
{ 
} 
*/ 


// Does use std::move 
Gizmo::Gizmo(Gizmo&& rhs) 
: foo_(std::move(rhs.foo_)) 
{ 
} 

int main() 
{ 
    typedef vector<Gizmo> Gizmos; 
    Gizmos gizmos; 
    generate_n(back_inserter(gizmos), 10000, []() -> Gizmo 
    { 
     Gizmo ret; 
     return ret; 
    }); 

    random_shuffle(gizmos.begin(), gizmos.end()); 

} 

En el código anterior, hay dos versiones de Gizmo::Gizmo(Gizmo&&) - uno utiliza a std::move realidad movimiento la shared_ptr, y el otro sólo copia el shared_ptr.

Ambas versiones parecen funcionar en la superficie. Una diferencia (la única diferencia que puedo ver) es en la versión no move, el recuento de referencia del shared_ptr se incrementa temporalmente, pero solo brevemente.

Normalmente seguiría adelante y move el shared_ptr, pero solo para ser claro y consistente en mi código. ¿Me estoy perdiendo una consideración aquí? ¿Debo preferir una versión sobre la otra para cualquier razón técnica?

Answer 1

El problema principal aquí no es la pequeña diferencia de rendimiento debido al incremento atómico extra y la disminución en shared_ptr, sino que la semántica de la operación es inconsistente a menos que realice un movimiento.

Aunque se supone que el recuento de referencia del shared_ptr solo será temporal, no existe dicha garantía en el idioma. El objeto fuente desde el que se está moviendo puede ser temporal, pero también podría tener una vida útil mucho más larga. Podría ser una variable llamada que ha sido fundido a una rvalue referencia (digamos std::move(var)), en cuyo caso, al no movimiento del shared_ptr todavía se está manteniendo compartían la propiedad con la fuente del movimiento, y si el destino shared_ptr tiene un alcance menor, entonces la vida útil del objeto puntiagudo se extenderá innecesariamente.

Answer 2

Se prefiere el uso de move: debe ser más eficiente que una copia porque no requiere el incremento atómico adicional ni la disminución del recuento de referencias.

Answer 3

He votado a favor la respuesta de James McNellis. Me gustaría hacer un comentario sobre su respuesta, pero mi comentario no encajará en el formato de comentario. Así que lo estoy poniendo aquí.

Una forma divertida de medir el impacto en el rendimiento de mover un shared_ptr frente a copiar uno es usar algo como vector<shared_ptr<T>> para mover o copiar un montón de ellos y medir el tiempo. La mayoría de los compiladores tienen una manera de activar/desactivar la semántica de movimiento especificando el modo de idioma (por ejemplo, -std = C++ 03 o -std = C++ 11).

Aquí es código Acabo de prueba en -O3:

#include <chrono> 
#include <memory> 
#include <vector> 
#include <iostream> 

int main() 
{ 
    std::vector<std::shared_ptr<int> > v(10000, std::shared_ptr<int>(new int(3))); 
    typedef std::chrono::high_resolution_clock Clock; 
    typedef Clock::time_point time_point; 
    typedef std::chrono::duration<double, std::micro> us; 
    time_point t0 = Clock::now(); 
    v.erase(v.begin()); 
    time_point t1 = Clock::now(); 
    std::cout << us(t1-t0).count() << "\u00B5s\n"; 
} 

Usando sonido metálico/libC++ y en -std = C++ 03 Esto muestra para mí:

195.368µs 

Cambio a - std = C++ 11 Obtengo:

16.422µs 

Su kilometraje puede variar.