Boost logo

Boost :

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

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