Subject: Re: [boost] unique_ptr for C++03
From: Andrew Ho (helloworld922_at_[hidden])
Date: 2013-08-03 14:39:38
> I would be very interested in seeing a C++03 based unique_ptr as part of
> Back in March there was some discussion about moving the unique_ptr
> implementation of Boost.Interprocess to Boost.SmartPtr. What happened
> to that proposal?
I actually didn't know Boost.Interprocess existed before. The interface
looks very similar to standard c++11 unique_ptr, and if it matches the
standard implementation as closely as possible, it would probably be a
better fit because the implementation is likely to be less buggy.
> Maybe you could use the safe-bool idiom.
Ah, thanks. Updated to use the safe-bool idiom.
> PS: I recommend that you use your real name in the copyright line rather
> than your handle. I do not think that the latter is legally valid.
Fair enough. Updated copywrite info.
Does anyone know of nullptr emulated type already in Boost (similar to
I think this would be the best way to allow this:
my_uptr = nullptr; // effectively my_uptr.reset();
if(my_uptr == nullptr) // technically valid, though not sure if there's
significant gains from verbose writing vs. if(my_uptr)
I did some testing trying to store my unique_ptr implementation into a
std::vector, and things did not go well using a C++03 compiler (standard
library templates obviously aren't move aware in C++03). I'm not sure
there's any way to fix this for C++03 without re-implementing the standard
library containers, which really isn't practical.
I think this implementation does work properly with array types.
// on p1 destruction, delete is called, as expected
boost::unique_ptr<int> p1(new int);
// compilation error, as expected
boost::unique_ptr<int> p2 = boost::move(p1);
// compiles, but so does std::unique_ptr
// both will produce undefined runtime behavior on destruction of held value
// dunno if this is GCC-4.8.1 specific, or if technically allowed by the
standard and is user error.
boost::unique_ptr<int> p3(new int);
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk