Должен ли я std :: переместить shared_ptr в конструкторе перемещения?

Question

Рассмотрим:

#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()); 

} 

В приведенном выше коде, есть две версии Gizmo::Gizmo(Gizmo&&) - один использует std::move на самом деле движениеshared_ptr, а другие просто копирует shared_ptr.

Оба варианта, похоже, работают на поверхности. Одна разница (единственная разница, которую я вижу) находится в версии не move, счетчик ссылок shared_ptr временно увеличивается, но только ненадолго.

Я бы обычно пошел дальше и shared_ptr, но только для того, чтобы быть четким и последовательным в моем коде. Я пропустил здесь рассмотрение? Должен ли я предпочесть одну версию над другой для любой технической причины?

Answer 1

Основная проблема здесь заключается не в небольшой разнице в производительности за счет дополнительного атомного прироста и уменьшения в shared_ptr, но что семантика операции несовместима, если вы не выполняете движение.

Хотя предполагается, что счетчик ссылок shared_ptr будет временным, на этом языке нет такой гарантии. Исходный объект, из которого вы перемещаетесь, может быть временным, но он также может иметь гораздо более продолжительный срок службы. Это может быть названа переменная, которая была литая к RValue ссылок (скажем std::move(var)), в этом случае, не движущихся от shared_ptr вы все еще сохраняя совместно собственность с источником движения, и если пункт назначения shared_ptr имеет меньшую область действия, тогда время жизни остроконечного объекта будет излишне расширенным.

Answer 2

Предпочтительно использование move: оно должно быть более эффективным, чем копия, потому что не требует дополнительного атомного приращения и уменьшения счетчика ссылок.

Answer 3

Я поддержал ответ Джеймса Макнеллиса. Я хотел бы прокомментировать его ответ, но мой комментарий не будет соответствовать формату комментария. Поэтому я помещаю его здесь.

Восхитительный способ измерения воздействия перемещения shared_ptr против копирования - это использовать что-то вроде vector<shared_ptr<T>>, чтобы переместить или скопировать целую кучу и время. Большинство компиляторов имеют возможность включить/выключить семантику перемещения, указав языковой режим (например, -std = C++ 03 или -std = C++ 11).

Вот код, который я только что протестировал на -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"; 
} 

Использование лязг/LibC++ и -std = C++ 03 печатается для меня:

195.368µs 

Переключение на - std = C++ 11 Получаю:

16.422µs 

Ваш пробег может отличаться.