Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2001-01-06 11:37:21


David Abrahams wrote on 1/6/2001 11:25 AM

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

Using CW, and yes wary of what you are speaking of (which is in itself in
some flux in the standard if I recall). And found a couple more holes in
this animal...

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

I'm up to requiring this in the primary:

private:
        X* ptr_;
        template<class Y> auto_ptr(auto_ptr<Y[]>& a) throw();
        template<class Y> operator auto_ptr<Y[]>() throw();
        template<class Y> auto_ptr& operator=(auto_ptr<Y[]>&) throw();
        template<class Y> operator auto_ptr_ref<Y[]>() throw();

And at the risk of being too clever, I renamed auto_ptr_array_ref to:

template <class Y>
struct auto_ptr_ref<Y[]>
{
        Y* ptr_;
};

And have the specialization refer to auto_ptr_ref<X[]> instead of
auto_ptr_ref<X>. I believe it has the same effect.

-Howard


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk