I am confused with unique_ptr and rvalue move philosophy.
Let's say we have two collections:
std::vector<std::auto_ptr<int>> autoCollection; std::vector<std::unique_ptr<int>> uniqueCollection;
Now I would expect the following to fail, as there is no telling what the algorithm is doing internally and maybe making internal pivot copies and the like, thus ripping away ownership from the auto_ptr:
std::sort(autoCollection.begin(), autoCollection.end());
I get this. And the compiler rightly disallows this happening.
But then I do this:
std::sort(uniqueCollection.begin(), uniqueCollection.end());
And this compiles. And I do not understand why. I did not think unique_ptrs could be copied. Does this mean a pivot value cannot be taken, so the sort is less efficient? Or is this pivot actually a move, which in fact is as dangerous as the collection of auto_ptrs, and should be disallowed by the compiler?
I think I am missing some crucial piece of information, so I eagerly await someone to supply me with the aha! moment.
Use unique_ptr when if you want to have single ownership(Exclusive) of resource. Only one unique_ptr can point to one resource. Since there can be one unique_ptr for single resource its not possible to copy one unique_ptr to another.
Why is auto_ptr deprecated? It takes ownership of the pointer in a way that no two pointers should contain the same object. Assignment transfers ownership and resets the rvalue auto pointer to a null pointer. Thus, they can't be used within STL containers due to the aforementioned inability to be copied.
"Moving" transfers ownership to a new unique_ptr and resets the old unique_ptr .
unique_ptr::getReturns a pointer to the managed object or nullptr if no object is owned.
I think it's more a question of philosophy than technic :)
The underlying question is what is the difference between Move and Copy. I won't jump into technical / standardista language, let's do it simply:
As you said, it is possible to implement Move in term of Copy: create a copy into the new location and discard the original. However there are two issues there. One is of performance, the second is about objects used for RAII: which of the two should have ownership ?
A proper Move constructor solves the 2 issues:
The auto_ptr
and unique_ptr
are a very good illustration of this.
With an auto_ptr
you have a screwed Copy semantic: the original and the copy don't compare equal. You could use it for its Move semantic but there is a risk that you'll lose the object pointed to somewhere.
On the other hand, the unique_ptr
is exactly that: it guarantees a unique owner of the resource, thus avoiding copying and the inevitable deletion issue that would follow. And the no-copy is guaranteed at compile-time too. Therefore, it's suitable in containers as long as you don't try to have copy initialization.
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)
So you can use unique_ptr
in a container (unlike auto_ptr
), but a number of operations will be impossible because they involve copying which the type does not support.
Unfortunately Visual Studio may be quite lax in the enforcement of the standard and also has a number of extensions that you would need to disable to ensure portability of the code... don't use it to check the standard :)
The unique_ptr
s are being moved using their move constructor. unique_ptr
is Movable, but not CopyConstructable.
There's a great article on rvalue references here. If you haven't read about them yet, or are confused, take a look!
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With