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
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
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk