[boost] Re: auto_ptr "generic ancestor" idea

From: Kevin Atkinson (kevinatk_at_[hidden])
Date: 2000-03-29 03:49:17

On Wed, 29 Mar 2000, Kevin Atkinson wrote:

> On Wed, 29 Mar 2000, Ian Bruntlett wrote:
> 
> > Kevin,
> > 
> > > And this means....... How exactly is auto_ptr not sufficient.  I really
> > > don't know what you are trying to do.  What are your existing practices.
> > 
> > Well, I don't think auto_ptr<> would be suitable for use when dealing with,
> > say O.S. handles.
> > 
> > I think that to use auto_ptr<> with an O.S. handle I'd have to write a guard
> > class for every kind of O.S. handle.
> > 
> > It would only be a matter of time before individual guard classes started
> > having different interfaces and quirks.
> > 
> > If I use auto_resource<>, I'd only have to implement two member functions,
> > reset() and release(). The class interface would be consistent - as long as
> > reset() and release() were implemented correctly.
> > 
> 
> 1) I assume you want to free the OS handle when you are done.  Well each OS
>    handle will have to be freed in a different way.  So you will still 
>    need to have a different specialization of auto_resource for each handle.
> 
> 2) You are making things more complicated than they need to be.  The only
>    thing you should really have to worry about is how to free the handle
>    when you are done with it.  All you need to do is implement a single
>    method.
> 
> 3) Your model 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.

4) How will you tell one resource apart from another.  Many OS handles are
typedefines of a basic type so there is no real way to tell one os handle
from another.  Having specializations of a generic ancestor based only on
the type of a resource assumes the compiler can tell one resource apart
from another.

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