|
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