[move] unique_ptr converting constructor
While looking at https://svn.boost.org/trac/boost/ticket/11259 I found that after implementing a converting shared_ptr constructor that takes a boost::movelib::unique_ptr, the straightforward code in the ticket still fails (with g++ in C++03 mode): namespace mystd { using boost::shared_ptr; using boost::make_shared; using boost::movelib::unique_ptr; using boost::movelib::make_unique; } mystd::unique_ptr<int> load_thing() { return mystd::make_unique<int>(1); } mystd::shared_ptr<int> get_thing() { return load_thing(); } So, out of curiosity, I looked at how unique_ptr itself implements its converting constructor. It turns out that it, too, doesn't work. mystd::unique_ptr<int const> get_thing_2() { return load_thing(); } Furthermore, the two possible ways to make the shared_ptr code work: mystd::shared_ptr<int> get_thing() { mystd::shared_ptr<int> r( load_thing() ); return r; } mystd::shared_ptr<int> get_thing() { mystd::unique_ptr<int> r( load_thing() ); return boost::move( r ); } fail for the unique_ptr<int const> case.
El 04/05/2015 a las 1:23, Peter Dimov escribió:
While looking at
https://svn.boost.org/trac/boost/ticket/11259
I found that after implementing a converting shared_ptr constructor that takes a boost::movelib::unique_ptr, the straightforward code in the ticket still fails (with g++ in C++03 mode):
mystd::shared_ptr<int> get_thing() { mystd::unique_ptr<int> r( load_thing() ); return boost::move( r ); }
fail for the unique_ptr<int const> case.
Thanks Peter,
That's because the converting constructor is programed as taking
rv
Ion Gaztañaga wrote:
That's because the converting constructor is programed as taking rv
> (similar to unique_ptr &&) and that provokes emulation limitations when returning by value convertible types.
Yes. I tried to give it the result of boost::move, which should be rv<>, but it still didn't work. By value has its own limitations, as described. This aside, ought not unique_ptr and make_unique be in boost instead of movelib? I'll remove boost::make_unique if we do this.
El 06/05/2015 a las 0:13, Peter Dimov escribió:
This aside, ought not unique_ptr and make_unique be in boost instead of movelib? I'll remove boost::make_unique if we do this.
No problems on my side, we just need to discuss if boost::movelib::unique_ptr's quality is enough to become the "official" unique_ptr implementation in Boost. Best, Ion
Le 06/05/15 08:55, Ion Gaztañaga a écrit :
El 06/05/2015 a las 0:13, Peter Dimov escribió:
This aside, ought not unique_ptr and make_unique be in boost instead of movelib? I'll remove boost::make_unique if we do this.
No problems on my side, we just need to discuss if boost::movelib::unique_ptr's quality is enough to become the "official" unique_ptr implementation in Boost.
Hi, I'm all for having an "official" boost::unique_ptr class that works as much as possible as std::unique_ptr. Please, let it have it for the next release. Vicente
Ion Gaztañaga wrote:
El 06/05/2015 a las 0:13, Peter Dimov escribió:
This aside, ought not unique_ptr and make_unique be in boost instead of movelib? I'll remove boost::make_unique if we do this.
No problems on my side, we just need to discuss if boost::movelib::unique_ptr's quality is enough to become the "official" unique_ptr implementation in Boost.
It's not like it has any competition. :-)
El 06/05/2015 a las 14:07, Peter Dimov escribió:
Ion Gaztañaga wrote:
El 06/05/2015 a las 0:13, Peter Dimov escribió:
This aside, ought not unique_ptr and make_unique be in boost instead of > movelib? I'll remove boost::make_unique if we do this.
No problems on my side, we just need to discuss if boost::movelib::unique_ptr's quality is enough to become the "official" unique_ptr implementation in Boost.
It's not like it has any competition. :-)
Even if no one writes an alternative implementation, it should be "good enough". Otherwise, it can be an utility in Boost.Move as it previously was in Boost.Interprocess. Another issue is if we should put it into Boost.SmartPtr or not, specially the documentation. To minimize th work we can add a small section in Boost.SmartPtr's documentation that points to Boost.Move documentation, as someone looking for boost::unique_ptr is likely to start looking in Boost.SmartPtr. Best, Ion
On Wed, May 6, 2015 at 4:55 PM, Ion Gaztañaga
Another issue is if we should put it into Boost.SmartPtr or not, specially the documentation. To minimize th work we can add a small section in Boost.SmartPtr's documentation that points to Boost.Move documentation, as someone looking for boost::unique_ptr is likely to start looking in Boost.SmartPtr.
+1 to "someone looking for boost::unique_ptr is likely to start looking in Boost.SmartPtr". I think it is logical to have it in Boost.SmartPtr (implementation, docs and tests).
El 06/05/2015 a las 0:13, Peter Dimov escribió:
Ion Gaztañaga wrote:
That's because the converting constructor is programed as taking rv
> (similar to unique_ptr &&) and that provokes emulation limitations when returning by value convertible types. Yes. I tried to give it the result of boost::move, which should be rv<>, but it still didn't work.
By value has its own limitations, as described.
Would this help? https://github.com/boostorg/move/commit/4a44ed3d26d299cab60950e90447648bdbf0... Ion
participants (4)
-
Andrey Semashev
-
Ion Gaztañaga
-
Peter Dimov
-
Vicente J. Botet Escriba