[boost] Re: auto_ptr "generic ancestor" idea

From: Ian Bruntlett (Ian.Bruntlett_at_[hidden])
Date: 2000-03-29 03:58:52

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.

> 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.

> 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?

Ian