Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-30 12:01:23

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message

>> And whatever that smart pointer is called, I think:
>> initialize(std::auto_ptr<X>& p) {
>> px_.reset(p.release());
>> }
>> is much preferred since it explicitly says what is happening, and
>> decouples typeof(px_) from std::auto_ptr.
>> Sometimes less is more.

On Monday, September 30, 2002, at 12:13 PM, Ed Brey wrote:

> I infer from this that you would then be in favor of dropping the
> auto_ptr overload on the constructor.

Yes, that is a fair statement (and dropping reset too). Although I
should qualify this statement with one of backward compatibility and
migration. We can't do what I suggest until there has been an
alternative smart pointer available for some period of time.

> I partially understand the appeal of keeping the semantics narrow,
> although only if applied with complete consistency to all methods.

Agreed, consistency is very important.

> The one point that I am struggling to grasp is how having no transfer
> semantics is better than having only transfer in semantics. Given
> that the new expression for the pointee is outside of scoped_ptr, in
> reality it *needs* transfer in semantics. Given that they exist, how
> is it better to restrict them than to make it general feature?

Agree 100% that you need transfer semantics for this application. I
think we need another smart pointer. From the scoped_ptr documentation:

> The scoped_ptr template is a simple solution for simple needs. It
> supplies a basic "resource acquisition is initialization" facility,
> without shared-ownership or transfer-of-ownership semantics. Both its
> name and enforcement of semantics (by being noncopyable) signal its
> intent to retain ownership solely within the current scope. Because it
> is noncopyable, it is safer than shared_ptr or std::auto_ptr for
> pointers which should not be copied.

The main motivation for scoped_ptr seems to be as local auto variable
in a function. If scoped_ptr has no transfer semantics, then the
reader of such a function knows immediately what the role of this
smart_ptr is within that function. There is no need to read further to
find out if ownership is going to be transferred out of the function.

> A related question is how does adding the word release make the
> example any clearer, unless you would also do the same when
> transfering to shared_ptr?

I'm all for consistency! :-) Imho, transferring resources with syntax
that looks like copy semantics is a bad idea, no matter what the name
of the classes involved. Given some generic code:

T t;
U u(t);

This looks like copy. Sometimes it is not. Imo when it is not copy,
it is suboptimal code. I think it would be better to do:

T t;
U u(t.release());

Or perhaps some other syntax to signify that t is being pilfered and
not copied.

Moving resources with copy syntax can lead to difficult-to-detect run
time errors in generic code. This is best prevented by not creating
concrete types that move with copy syntax (which may some day be put
into generic code which subtly expects copy semantics).


Boost list run by bdawes at, gregod at, cpdaniel at, john at