Re: auto_ptr vs. boost shared_ptr
Howard Hinnant wrote:
In article <e9e9gs$7ma$1@nntp.aioe.org>,
James Kanze <kanze.james@neuf.fr> wrote:
I'll read the paper first, but off hand, I see several
incompatible requirements. Or does the pointer uses some
sort of policies to determine its behavior.
There is one policy: a deleter (analogous to a container's allocator):
template <class T, class D = default_delete<T> >
class unique_ptr;
But I would not call this a policy-based smart pointer as the
term is commonly used.
Me neither. Although it's a useful feature---almost all my uses
of boost::shared_ptr use it, and in at least one case, I'm using
a boost::shared_ptr even though the ownership semantics
correspond to auto_ptr, simply because auto_ptr doesn't have
this feature. (And it bothers me, because in this case, the
pointer is a return value, and I'm imposing an ownership policy
on the user---typically, not the one he really needs, too.)
unique_ptr has semantics very, very similar to auto_ptr
(unique ownership, to be contrasted with shared_ptr's
semantics of shared ownership).
OK. That's the main reason I use auto_ptr. (Note that I use
auto_ptr even with garbage collection, because of these
semantics.)
One can not copy a unique_ptr:
unique_ptr<int> u1(new int(1));
unique_ptr<int> u2(u1); // compile time error
However one can *move* from a unique_ptr using move syntax:
unique_ptr<int> u2(move(u1)); // ok
assert(u1.get() == 0);
assert(*u2 == 1);
I'm not sure how this works. How do you use it as a return
value? Or a parameter? As a parameter, I can always pass it
as a non-const reference, I suppose. But this means that the
client cannot pass a temporary: I have a lot of code along the
lines of:
messageQueue.send(
std::auto_ptr< Message >( new Type1Message( args ) ) ) ;
And of course, messageQueue.receive() returns an auto_ptr by
value, since it no longer has a copy to refer to.
Ownership transfer is essential.
Thus ownership transfer is both possible, and explicit, at
least from lvalues.
Ownership transfer is also possible from rvalues, but in this
case is implicit (uses copy syntax):
unique_ptr<T> factory();
unique_ptr<T> p = factory(); // ok, move from rvalue
And the same thing will work for arguments, I suppose. (And all
move really does is convert the lvalue to an rvalue?)
Sounds good. (The next obvious question is: where can I access
an implementation, to try it out? Since we all know that things
which sound good on paper don't always work out that well in
practice.)
In a pimpl,
I don't want to be able to copy the pointer; if I accidentally
copy it, I get a compile time error. When passing pointers to
objects between threads, I want to be sure that the thread
having passed the object can no longer access it. Both
requirements are, as far as I can see, incompabible with one
another, and both are incompatible with allowing containers of
the pointers.
One gets a compile time error if one copies (either copy
construction or copy assignment) an lvalue unique_ptr.
However ownership transfer happens with move(), or from an
rvalue.
That would at least cover the accidental cases (typically,
forgetting to provide or inhibit the copy constructor for the
pimpl). In this case, the fact that I can do it explicitly
isn't a feature, but it's not a critical defect either.
Despite the restriction on copy semantics, unique_ptr will go
into std::containers (unlike) auto_ptr. This is because
std::containers will use move internally, instead of copy.
vector<unique_ptr<int>> v;
v.push_back(unique_ptr<int>(new int(1))); // ok, moved in
Such a container is movable, but not copyable. It's elements
can be moved in or out of the container, but not copied in or
out of the container.
I'm not sure of the implications here. Given v, above, what
does v[0] return? What happens if I move it? What is left at
v[0] in the container?
Such containers of movable but non-copyable types will also be
able to be manipulated with many std::algorithms (which will
use swap/move instead of copy) such as sort, push/pop_heap,
partition, rotate, remove_if, etc. If an attempt is made to
use such a sequence with an algorithm that requires copy
semantics, a compile-time error will result.
Note that ownership transfer requires a non-const unique_ptr
source. If you want to prohibit ownership transfer from a
unique_ptr, (like scoped_ptr), make it const.
Which isn't always an option, e.g. if I want my pimpl to support
assignment.
In the end, it sounds like a good replacement for auto_ptr. I
think I'd rather prefer to have a scoped_ptr along side of it,
if for no other reason that it seems clearer to have two
distinctly named types for two different target semantics.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]