[boost] Re: auto_ptr "generic ancestor" idea

From: Ian Bruntlett (Ian.Bruntlett_at_[hidden])
Date: 2000-03-29 09:50:21

Kevin,

> > 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.
My objection is that a class is a much broader interface than the one I
intended to expose.
You are right, I have to use a class.

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

Here are my reasons for having two methods:-

release() needs to know a safe "empty" value for the resource being handled.
For pointer types this is 0. For many OS handles this is 0. Some OS handles
have an "empty" value of -1. This kind of specific information is used by
release().

The freeing up of the resource is handled by reset().

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

You'd pointed out in (3) that auto_reference<> doesn't extend well to other
smart pointer types. I agree. They weren't considered.
I thought that (3) implied the existence of a smart pointer type that does
extend well to other smart pointer types.

Ian