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