41 
std::unique_ptr<int> p1(new int); std::unique_ptr<int> p2(new int); p2=p1;

It seems here that p1 is no longer "unique" since p2 refer to it also

It is legal c++ ? Does unique_ptr have copy_semantics ? If no, and if it has only move semantics, is p1 set to NULL after assign it to p2 ?

EDIT:

ok so the correct version is

 p2=std::move(p1)

According to that, after this assign, p1 is not valid ? And the difference with auto_ptr is here? it is more safe to explictly specfiy transfer of ownership than implicitly as it is the case with auto_ptr I guess

Improve this question
4
  • 16
    @Andres: As someone who has found dozens of bugs in various C++ compilers, I'd argue that is not at all true, especially when it comes to relatively new (and relatively untested) language features like rvalue references. Commented Apr 11, 2011 at 14:39
  • @James This one works, though. :) Commented Apr 11, 2011 at 15:06
  • You can have a look here for typical usage of unique_ptr Commented Apr 13, 2013 at 20:06
  • p1 is holding a null pointer after 'p2 = std::move(p1);' Commented Feb 4, 2014 at 18:54

3 Answers 3

Reset to default
67

std::unique_ptr is non-assignable and non-copyable. You need to use std::move();

so 

p1 = std::move(p2);

Have a look here for more info.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

The link is broken.
broken link, can't access
12

Here is an article I wrote which answers your questions. I originally wrote this article to present an emulation of unique_ptr. However you can ignore the first few paragraphs dealing with the emulation and just start reading at "Basic Examples".

http://howardhinnant.github.io/unique_ptr03.html

Edit:

I had trouble distilling the above linked article down to something small enough to make a practical answer in this format. However here is my best shot:

The reason: Safety in generic code. One can not really make copies of either auto_ptr or unique_ptr. Consider:

template <class T> void foo(T t) { T copy_of_t = t; // line 4 assert(copy_of_t == t); }

It is not unusual at all for generic code to look like foo above. The assert is probably not actually there, but the assumption that the assert would hold often is there ... implicitly. Indeed, a popular implementation of std::sort had exactly this logic in 1996, which is exactly what prompted the second auto_ptr redesign (which helped, but didn't completely fix the problem).

Improve this answer

1 Comment

Thanks for the article :) It is considered good practice on SO to sum up the content of the link though, so that the answer does not lose its value if the link goes dead.
3

As per this, p2=p1 is a compilation error.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.