Правильная семантика копирования для std :: unique_ptr в качестве параметра - PullRequest
Новая
       20

Правильная семантика копирования для std :: unique_ptr в качестве параметра

2 голосов
/ 03 декабря 2011

Есть ли модификация интерфейса, которая может заставить работать второй вызов?

Или я должен оставить все как есть?

Я подозреваю, что дополнительная конструкция в первом случае была спроектирована таким образом, поэтому ясно, что право собственности передается. 

#include <memory>

struct Bar { };
typedef std::unique_ptr<Bar> UPBar;

void foo1( UPBar p ) {  }
void foo2( UPBar p ) { foo1( move( p )); }
void foo3( UPBar p ) { foo2( move( p )); }
void foo4( UPBar p ) { foo3( move( p )); }

int main(int argc, char** argv)
{
    UPBar p( new Bar );
    foo4( move( p ));  // ok, but requires an extra construction vs line below
    foo4( new Bar );   // fails: any modification to get this to work?

    return 0;
}

Второй вопрос: если я изменю все параметры, переданные в RValue-References (&&), есть ли какие-либо недостатки в этом? Фактически, я должен гарантировать, что все мои std::unique_ptr<> параметры переданы RValue-References?

1 Ответ

2 голосов
/ 03 декабря 2011

Вы можете создать unique_ptr как временное: 

foo4( UPBar( new Bar ));

Вы также можете написать шаблон функции make_unique, аналогичный make_shared, существующему для shared_ptr: 

template <typename T, typename... Args>
std::unique_ptr<T> make_unique(Args&&... args) {
    return std::unique_ptr<T>(new T(std::forward<T>(args)...));
}

foo4( make_unique<Bar>() );
// other constructors are also callable:
foo4( make_unique<Bar>(x, y, z) );
...