Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-01-28 11:32:43

From: "David B. Held" <dheld_at_[hidden]>
> "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> news:009f01c2c6d7$91024ab0$1d00a8c0_at_pdimov2...
> > [...]
> > The first question, of course, is: do you really need SmartPtr<...> to
> > support move semantics (in current C++)?
>
> Why wouldn't you want that?

:-)

You can use this argument for any feature. But you can't include all
features.

> At the very least, it seems like a glaring
> omission to create a smart pointer framework that can't even emulate
> auto_ptr<>.

It depends on what your design goals are. If you want to create the One True
Smart Pointer Design, then yes, auto_ptr<> emulation is a must.

If, on the other hand, you want to create the Design That Solves Common User
Needs, auto_ptr<> emulation isn't high on the list. If I need auto_ptr I
know where to find it, and nobody I know has ever written an auto_ptr
(amusement aside.) :-)

> Beyond that, it seems that there are resources that would
> benefit from or outright require move semantics to work properly, and
> why wouldn't you want to let SmartPtr<> manage those?

Interesting question. Do you have an example?

Also note that I said "in current C++" (that's rather move semantics
unfriendly.) Given language support for move (N1377 for example), it would
make perfect sense to extend SmartPtr with move semantics, of course.

http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1377.htm