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
>> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk