Andrei suggested that I pose this question to several groups, as
it is relevant to all of them. While the problem was originally identified
by Richard Crossley, Andrei sums it up pretty well right here:
The problem is, auto_ptr's behavior relies on the chain:
smart_ptr -> operator by_ref() -> smart_ptr(by_ref)
My understanding is that the template constructor:
template
<
typename T1,
template <class> class OP1,
class CP1,
template <class> class KP1,
template <class> class SP1
>
SmartPtr(SmartPtr<T1, OP1, CP1, KP1, SP1> const& rhs)
is going to somehow get in the way by "eating" everything,
and in particular not allow the constructor:
SmartPtr(ByRef<SmartPtr> rhs)
to kick in, as it should.
As you can see, the conversion c'tor for smart_ptr interferes with
the by_ref c'tor when the pointer is configured for auto_ptr<>
semantics. That's because:
smart_ptr(smart_ptr<U> const&);
requires no conversions, while
smart_ptr(by_ref<smart_ptr>);
requires one. Richard suggests partially specializing smart_ptr
so that the auto_ptr<> configuration only has:
smart_ptr(smart_ptr<U>&);
while the standard version has both (or just the const& version).
Andrei suggests something similar, but uses explicit aggregation
instead of private inheritance from a common base class.
My questions are thus:
A) Is this indeed the simplest, best solution?
B) Is there a way to solve this problem without creating partial
specializations, regardless of the answer to A)?
It occurs to me that only providing a smart_ptr(smart_ptr<U>&)
conversion c'tor solves the problem. But this would disallow
conversion from rvalues in non-auto_ptr<> configurations, no?
Dave
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
