This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

687. shared_ptr conversion constructor not constrained

Section: 20.3.2.2.2 [util.smartptr.shared.const], 20.3.2.3.2 [util.smartptr.weak.const] Status: CD1 Submitter: Peter Dimov Opened: 2007-05-10 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [util.smartptr.shared.const].

View all issues with CD1 status.

Discussion:

Since all conversions from shared_ptr<T> to shared_ptr<U> have the same rank regardless of the relationship between T and U, reasonable user code that works with raw pointers fails with shared_ptr:

void f( shared_ptr<void> );
void f( shared_ptr<int> );

int main()
{
  f( shared_ptr<double>() ); // ambiguous
}

Now that we officially have enable_if, we can constrain the constructor and the corresponding assignment operator to only participate in the overload resolution when the pointer types are compatible.

Proposed resolution:

In 20.3.2.2.2 [util.smartptr.shared.const], change:

-14- Requires: For the second constructor The second constructor shall not participate in the overload resolution unless Y* shall be is implicitly convertible to T*.

In 20.3.2.3.2 [util.smartptr.weak.const], change:

template<class Y> weak_ptr(shared_ptr<Y> const& r);
weak_ptr(weak_ptr const& r);
template<class Y> weak_ptr(weak_ptr<Y> const& r);
weak_ptr(weak_ptr const& r);
template<class Y> weak_ptr(weak_ptr<Y> const& r);
template<class Y> weak_ptr(shared_ptr<Y> const& r);

-4- Requires: For tThe second and third constructors, shall not participate in the overload resolution unless Y* shall be is implicitly convertible to T*.