[Move] unique_ptr
Hi, with now accepted Move library, is implementation of unique_ptr<> planned for boost? I used to use Howard Hinnant's implementation so far but got compilation problems as soon as I added Move library to my toolbox. Also, Hinnant's page says: "The following is a dated C++03 emulation of unique_ptr. You may find a better unique_ptr emulation at boost." Does he mean the one in Boost.Interprocess? Regards, Simon
El 30/10/2011 16:40, Szymon Gatner escribió:
Hi,
with now accepted Move library, is implementation of unique_ptr<> planned for boost? I used to use Howard Hinnant's implementation so far but got compilation problems as soon as I added Move library to my toolbox. Also, Hinnant's page says:
"The following is a dated C++03 emulation of unique_ptr. You may find a better unique_ptr emulation at boost."
I think it's a missing part. I would like to propose it but I have no time at this moment.
Does he mean the one in Boost.Interprocess?
I think boost::interprocess::unique_ptr can miss some std::unique_ptr features (I wrote it many months ago and I haven't checked the standard requirements) . Now that we have move-aware containers in Boost.Container, boost::unique_ptr would very useful, maybe boost::interprocess::unique_ptr is a good starting point. Maybe you can try it with boost::container and tell us how it feels. Ion
on Sun Oct 30 2011, Ion Gaztañaga
El 30/10/2011 16:40, Szymon Gatner escribió:
Hi,
with now accepted Move library, is implementation of unique_ptr<> planned for boost? I used to use Howard Hinnant's implementation so far but got compilation problems as soon as I added Move library to my toolbox. Also, Hinnant's page says:
"The following is a dated C++03 emulation of unique_ptr. You may find a better unique_ptr emulation at boost."
I think it's a missing part. I would like to propose it but I have no time at this moment.
Does he mean the one in Boost.Interprocess?
I think boost::interprocess::unique_ptr can miss some std::unique_ptr features (I wrote it many months ago and I haven't checked the standard requirements) . Now that we have move-aware containers in Boost.Container, boost::unique_ptr would very useful, maybe boost::interprocess::unique_ptr is a good starting point. Maybe you can try it with boost::container and tell us how it feels.
Maybe http://www.coderage.com/move_ptr/libs/move_ptr/doc/home.html would be a good place to start. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Hi,
I think boost::interprocess::unique_ptr can miss some std::unique_ptr features (I wrote it many months ago and I haven't checked the standard requirements) . Now that we have move-aware containers in Boost.Container, boost::unique_ptr would very useful, maybe boost::interprocess::unique_ptr is a good starting point. Maybe you can try it with boost::container and tell us how it feels.
Just including container/vector.hpp and interprocess/smart_ptr/unique_ptr.hpp gives: "warning C4005: 'BOOST_RV_REF' : macro redefinition C:\devel\boost_1_47_0_NO_SCL\boost\interprocess\detail\move.hpp" and many more of those. second thing is lack of default deleter so simplest code like: interprocess::unique_ptr<Foo> upr; is invalid.
Maybe http://www.coderage.com/move_ptr/libs/move_ptr/doc/home.html would be a good place to start.
Imho easiest to adopt would be Hinant's implementation: http://home.roadrunner.com/~hinnant/unique_ptr03.html It uses own rvalue reference/move emulation which would just need to be replaced with Boost.Move. I'll try doing that and see how it works with Boost.Container. Cheers, Simon
Hi again,
Imho easiest to adopt would be Hinant's implementation:
replying to myself, I know, but wanted to share ;)
Just played with modified Hinant's and Ion's (sorry for not crediting earlier
just noticed your name in copyright's info) and it all seems to work properly.
My simple test code:
int main()
{
using namespace boost;
// Foo is marked MOVABE_BUT_NOT_COPYABLE
unique_ptr<Foo> f1(new Foo), f2(new Foo), f3(new Foo);
container::vector
Hi, Could anyone take a look at attached implementation? Most of it is actually custom version of compressed_pair (should boost one be used instead?). What about including it to boost? Cheers, Simon
on Mon Nov 07 2011, Szymon Gatner
Hi,
Could anyone take a look at attached implementation? Most of it is actually custom version of compressed_pair (should boost one be used instead?). What about including it to boost?
There's no attachment here AFAICT. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Hi,
There's no attachment here AFAICT.
It was in my earlier email containing more detailed info of what I did, but in nutshell I took base implementation from: http://home.roadrunner.com/~hinnant/unique_ptr03.html and replaced custom move semantics / emulation with newly accepted boost::move code. Cheers, Simon
on Tue Nov 08 2011, Szymon Gatner
Hi,
There's no attachment here AFAICT.
It was in my earlier email containing more detailed info of what I did, but in nutshell I took base implementation from:
http://home.roadrunner.com/~hinnant/unique_ptr03.html
and replaced custom move semantics / emulation with newly accepted boost::move code.
OK, I took a look. It seems fine to me! -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Wed Nov 09 2011, Szymon Gatner
OK, I took a look. It seems fine to me!
So how about including it to boost? ;)
I support the idea. If you want it to be its own library, you need to go through the review process. However, I suggest you get Peter Dimov's attention to see if he'll include it in the smart_ptr library.
P.S. Should custom implementation leveraging EBO for deleter (unique_ptr_storage class) be replaced with compressed_pair or not depending on additional library is more desirable in that case?
If you want Peter to accept it, I think you should leave the custom implementation in. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
Dave Abrahams -
Ion Gaztañaga -
Szymon Gatner