Boost logo

Boost :

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


> > If I use auto_resource<>, I'd only have to implement two member
> > reset() and release(). The class interface would be consistent - as long
> > reset() and release() were implemented correctly.
> 1) I assume you want to free the OS handle when you are done. Well each
> 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
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

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at