Re: [boost] Smart pointers and array types

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-01-06 11:25:19

----- Original Message -----
From: "Howard Hinnant" <hinnant_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 06, 2001 11:02 AM
Subject: Re: [boost] Smart pointers and array types

> David Abrahams wrote on 1/6/2001 10:38 AM
>
> >I think this is a mistake. Conversions to/from auto_ptr_ref<X> allow us
to
> >convert between auto_ptr<X> to auto_ptr<X[]>, which will call the wrong
> >version of delete. I think you need to use a new class, e.g.
> >auto_ptr_array_ref, to do this. And since you aren't depending on details
of
> >auto_ptr_ref any more, it should work portably.
>
> Excellent eye Dave!
>
> Unfortunately your suggested fix does not solve the problem.  Even with
> auto_ptr_array_ref the member template copy constructor and member
> template conversion operators of the primary template allow conversions
> both ways:
>
> template<class Y> auto_ptr(auto_ptr<Y>& a) throw();
> template<class Y> operator auto_ptr<Y>() throw();

I see that.

> However, adding the following to the primary template's private section
> seems to do the trick:
>
> template<class X>
> class auto_ptr
> {
> ...
> private:
> X* ptr_;
>
> template<class Y> auto_ptr(auto_ptr<Y[]>&) throw();
> template<class Y> operator auto_ptr<Y[]>() throw();
> };
>
> This even works with the specialization using auto_ptr_ref as originally
> proposed.  I'm not positive I fully understand the reasons.

If you're just using CW to test it, you may not be seeing exactly the right
behaviors. As you know, auto_ptr<> depends on some obscure areas of
conformance which to my knowledge, CW has never got quite right.

Also, are you using Greg Colvin's test program? auto_ptr_ref only comes into
play in a few cases, which maybe you're not exercising.

> There may be other/better ways of shorting out this unwanted conversion.

It looks like there's no way to avoid intruding on the primary template :(
Those template conversion operators can be implemented entirely in terms of
public member functions which we could not reasonably remove from the
interface of the specialized template.

-Dave