[boost] Re: auto_ptr "generic ancestor" idea

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

On Wed, 29 Mar 2000, Ian Bruntlett wrote:

> Kevin,
> 
> > > 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.
> Yes, I can live with that. Typically it will be a trivial O.S. call to
> release the handle.

So you STILL have to write code for each different specialization.  What
is you objection to creation a class to handle the necessary work and
passing that class in as a parameters.  It will involve just as much
code and will work when the compiler can't tell two different resources
apart as many OS handles are simply typedef of a integral type.

 > 
> > 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.
> Yes, I suppose so. A "relative" of auto_resource<> could be dumb_resource<>
> in which the user provides a template specialisation destructor. The access
> operators would not be implemented and the resource would be a public data
> member.
> 
> OTOH, auto_ptr<> has a concept of ownership which is helpful in avoiding
> some common pointer problems.
> 
> I think that its concept of ownership would be helpful in avoiding similar
> problems with OS handles.

No, you misunderstood me.  Have the reset() and release() members call
another method which will handle freeing the resource.  This way you only
have to implement the trivial call to free the resource and not anything
else.  This will also extend to other smart parter types with different
semantics such as a referencing counting smart 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?

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