[boost] Re: Re: Querying the Interest in a new AutoPtr class?

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-02-13 15:15:32

Chris Just wrote:
> Jonathan Turkanis wrote:
>> There is a policy-based pointer, based on the Loki SmartPtr, coming
>> up for review soon which can emulate an auto_ptr and allows deletion
>> policy to be specified as part of the 'storage policy'.
>
> I don't know much about the Loki SmartPtr, but it sounds like it
> might be a little hard to use if you need to setup policies...

It comes with a collection of ready made policies, including policies for
auto_ptr and move_ptr (at least it will soon).

> I wanted to create a very simple AutoPtr that was essentially the same
> as the STL auto_ptr (and backwards compatible with it).

Unfortunately, you haven't (see below). Furthermore, auto_ptr is widely
recognized as unsafe because it is too easy to transfer ownership
unintentionally.

>> I only looked very briefly, but I don't see how your auto_ptr can be
>> returned from functions. Also, why do you need the m_Owner variable?
>
> Correct me if I'm wrong, but wasn't there a specific reason why the
> STL auto_ptr was made so it couldn't be passed to or returned from a
> function?

This was true of the initial version. The standard version, which is version 3,
implements a flavor of move semantics (and it doesn't quite work).

> Anyways, if you want to pass or return the pointer to/from a
> function, just use the .get() or .release() functions.

But this subverts the resource management system.

> I need the m_Owner variable to tell me if I own the pointer before I
> delete it.

For auto_ptr, checking that the stored pointer is non-null should be sufficient.

Jonathan