[boost] Re: auto_ptr "generic ancestor" idea

From: Kevin Atkinson (kevinatk_at_[hidden])
Date: 2000-03-29 10:26:45

On Wed, 29 Mar 2000, Ian Bruntlett wrote:

> Here are my reasons for having two methods:-
> 
> release() needs to know a safe "empty" value for the resource being handled.
> For pointer types this is 0. For many OS handles this is 0. Some OS handles
> have an "empty" value of -1. This kind of specific information is used by
> release().
> 
> The freeing up of the resource is handled by reset().

So then pass in a class with 2 members one "free" and another
"is_null".  This will then extend better to other smart pointers types
then writing a specific methods for auto pointer.
> 
> > > > 3) Your module won't extend well to other smart pointers types which
> are
> > > >    not as simple as auto_ptr such as boost's referencing counting
> smart
> > > >    pointer.
> > > I hadn't considered that. Could you recommend a smart pointer type that
> does
> > > extend well to other smart pointer types?
> > What do you mean by that?
> 
> You'd pointed out in (3) that auto_reference<> doesn't extend well to other
> smart pointer types. I agree. They weren't considered.
> I thought that (3) implied the existence of a smart pointer type that does
> extend well to other smart pointer types.

You are looking for an interface.  I am looking for a general method to
extend all smart pointers.  That general method in my view is to pass in a
class with the necessary information so that the smart pointer can do its
job.  For most pointers this means one to free the resource and another to
tell if it is null.   For some resources there is no null and 
auto_resource should then insists that the resource is always pointing to
something valid.

Also, you are also repeatedly ignoring the fact that you specializations
won't work one the compiler can't tell one resource from another because
there are both represented by an integer!

---
Kevin Atkinson
kevinatk_at_[hidden]
http://metalab.unc.edu/kevina/