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

From: David B. Held (dheld_at_[hidden])
Date: 2003-01-28 14:07:09

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:004501c2c6f8$970c7400$1d00a8c0_at_pdimov2...
> From: "David B. Held" <dheld_at_[hidden]>
> [...]
> Nope, but I want my sink strongly exception safe; the pointer should
> be deleted when a policy constructor throws.

Hmm...that's not a bad point.  A function try block should make this
possible, no?

> While you're at it, make the sink support deep const (for deep copies,
> for example.)

Don't tempt me!

> More support for almost_default_storage_but_with_this_deleter
> would be nice to have, too.

This is a little harder...too many template c'tors. :(

> Apologies if the above issues have been addressed two years ago. I'm
> not familiar with the latest & greatest SmartPtr. ;-)

Touche. ;)

> [...]
> Yes, I understand that, but do you know of a user that needs an
> almost_auto_ptr? ;-)

Given how often people write auto_ptr<> without writing auto_ptr<>,
I'd say yes. ;>

> [...]
> Move semantics in general could be useful, true, but
> vector<auto_ptr> isn't supported, and it seems that this is a deliberate
> design decision.

So was auto_ptr<> to begin with, and now we have Greg Colvin calling
it an "ugly hack that needn't be replicated."  Apparently, not all
deliberate
decisions are the best ones. ;)

> Your memory is failing you, by the way. ;-)
>
> http://lists.boost.org/MailArchives/boost/msg29886.php
> http://lists.boost.org/MailArchives/boost/msg29925.php

I have shamed the family. <:(

> [...]
> So move-enabling SmartPtr would only help me if I use it directly. In
> cases like the above, though, I'll probably want to wrap it in a dedicated
> move_lock class, since a lock is a very specific kind of SmartPtr, and it
> might be desirable to prevent users from passing it to functions where a
> SmartPtr is expected.

I dunno.  A lock is also a very simple kind of SmartPtr, and it seems to
me a simple typedef will have the same effect.

typedef SmartPtr<my_mutex, LockPolicy, MovePolicy> SmartLock;

The only way you could pass this to a SmartPtr function is if there were
a conversion c'tor from LockPolicy to [SomePointerOwnershipPolicy].
If you're writing ownership policies for pointers that can be c'ted from a
LockPolicy, you *ought* to be the victim of your own folly.

Dave