C++0x Error: overloading a function with std::shared_ptr to const argument is ambiguous

Question

Suppose I have two unrelated classes A and B. I also have a class Bla that uses boost::shared_ptr like this:

class Bla {
public:
    void foo(boost::shared_ptr<const A>);
    void foo(boost::shared_ptr<const B>);
}

Notice the const. That's the important part which the original version of this question lacked. This compiles, and the following code works:

Bla bla;
boost::shared_ptr<A> a;
bla.foo(a);

However, if I switch from using boost::shared_ptr to using std::shared_ptr in the above examples, I get a compilation error that says:

"error: call of overloaded 'foo(std::shared_ptr<A>)' is ambiguous
note: candidates are: void foo(std::shared_ptr<const A>)
                      void foo(std::shared_ptr<const B>)

Can you help me figure out why the compiler can't figure out which function to use in the std::shared_ptr case, and can in the boost::shared_ptr case? I'm using the default GCC and Boost versions from the Ubuntu 11.04 package repository which are currently GCC 4.5.2 and Boost 1.42.0.

Here is the full code that you can try compiling:

#include <boost/shared_ptr.hpp>
using boost::shared_ptr;
// #include <memory>
// using std::shared_ptr;

class A {};
class B {};

class Bla {
public:
    void foo(shared_ptr<const A>) {}
    void foo(shared_ptr<const B>) {}
};

int main() {
    Bla bla;
    shared_ptr<A> a;

    bla.foo(a);

    return 0;
}

By the way, this issue motivated me to ask this question about whether I should be using std::shared_ptr at all yet ;-)

The original question was incorrect in that it was missing a "const" in the template type of the shared_ptr. I fixed that and provided the full code example. — Alan Turing, Jun 12 '11 at 18:46
I'm using the default GCC and Boost versions from the Ubuntu 11.04 package repository which are currently GCC 4.5.2 and Boost 1.42.0. — Alan Turing, Jun 12 '11 at 18:51
@Lex I can reproduce the problem. It's not present when switching to a more recent GCC though. Perhaps you might want to test out gcc-snapshot, or manually install GCC 4.6 proper. — Luc Danton, Jun 12 '11 at 19:25
@Luc, great to hear. Thank you for providing a light at the end of the tunnel ;-) — Alan Turing, Jun 13 '11 at 04:33

Ben Voigt · Accepted Answer · 2011-06-13T00:58:55.587

7

shared_ptr has a template single-argument constructor, which is considered for the conversion here. That's what allows an actual parameter shared_ptr<Derived> to be supplied where a shared_ptr<Base> is needed.

Since both shared_ptr<const A> and shared_ptr<const B> have this implicit conversion, it's ambiguous.

At least in C++0x, the standard requires that shared_ptr use some SFINAE tricks to make sure that the template constructor only matches types that actually can be converted.

The signature is (see section [util.smartptr.shared.const]):

shared_ptr<T>::shared_ptr(const shared_ptr<T>& r) noexcept;
template<class Y> shared_ptr<T>::shared_ptr(const shared_ptr<Y>& r) noexcept;

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

Possibly the library hasn't yet been updated to comply with that requirement. You might try a newer version of libc++.

Boost won't work, because it's missing that requirement.

Here's a simpler test case: http://ideone.com/v4boA (This test case will fail on a conforming compiler, if it compiles successfully, it means the original case will be incorrectly reported as ambiguous.)

VC++ 2010 gets it right (for std::shared_ptr).

edited Jun 13 '11 at 00:58

answered Jun 12 '11 at 19:31

Ben Voigt

277,958
43
419
720

1

Normally, `shared_ptr`'s constructor has such an SFINAE construct with `std::is_convertible`. Unrelated classes shouldn't be convertible. – Xeo Jun 12 '11 at 19:42
@Xeo: The standard requires that EXACT signature. There's no SFINAE going on. Or have I missed something? Ok, yeah I've missed something. That signature isn't a converting constructor, it has two arguments. It's the next one down that's important. – Ben Voigt Jun 12 '11 at 19:51
@Ben: I should also read the edited answer, not just your comment. :P I've skimmed through the standard to find the relevant part, but you already did that. +1 – Xeo Jun 12 '11 at 20:03
@Xeo: `std::shared_ptr` is new in C++0x, isn't it? So there's no need to consider the C++03 wording. And Boost does NOT have the implicitly convertible requirement. – Ben Voigt Jun 12 '11 at 20:04
@Ben: Meh, C++0x should become the standard already, as I'm already referring to it as such... meant the FDIS of course. – Xeo Jun 12 '11 at 20:08
@Xeo: I tend to call C++0x "a" standard. C++03 is also "a" standard. Which one I use for "the" standard when talking about compiler bugs depends on the compiler version (i.e. its unreasonable to say a three-year old compiler has a bug if it doesn't implement C++0x changes). – Ben Voigt Jun 12 '11 at 20:10
@Ben, sorry, but could you clarify if passing a `shared_ptr` to a `foo(shared_ptr)` function is incorrect behavior, and requires a conversion like the one @Jon provides. The simpler test case is actually mixing A and B so it's a little different. – Alan Turing Jun 13 '11 at 00:56
@Lex: Sorry, just added an explanation to the test case. Your code should work with `std::shared_ptr` according to the C++ specification, it will not work with `boost::shared_ptr`. Unfortunately the version of g++ (or libc++) you are using doesn't correct implement the specification. I don't know if it's fixed in a newer version. – Ben Voigt Jun 13 '11 at 01:00

Motti · Answer 2 · 2011-06-12T14:27:10.250

6

The following compiles fine with GCC 4.5 and Visual Studio 10. If you say it doesn't compile in GCC 4.5.2 then it sounds like a compiler bug which you should report (but make sure that it really happens it's more likely that you made some sort of typo).

#include <memory>
class A{};
class B{};
class Bla {
public:
    void foo(std::shared_ptr<A>) {}
    void foo(std::shared_ptr<B>) {}
};

int main()
{
    Bla bla;
    std::shared_ptr<A> a;
    bla.foo(a);
}

edited Jun 12 '11 at 14:27

answered Jun 12 '11 at 14:11

Motti

110,860
49
189
262

1

It also compiles fine with Visual C++ 2010 SP1. – Sven Jun 12 '11 at 14:13
1

I can confirm this with GCC 4.5 as well. – Peter Alexander Jun 12 '11 at 14:14
Thank you guys. This answers the original question which had `shared_ptr` and not `shared_ptr` as it should have. It does indeed compile with both `boost::` and `std::` versions. The problem comes in when the const is added as the modified question now explains. – Alan Turing Jun 12 '11 at 18:47

Jon Purdy · Answer 3 · 2011-06-12T21:01:14.533

2

You can use std::static_pointer_cast to add the const qualification:

bla.foo(std::static_pointer_cast<const A>(a));

edited Jun 12 '11 at 21:01

answered Jun 12 '11 at 20:18

Jon Purdy

53,300
8
96
166

There *is* an automatic conversion. See @Ben's answer. – Xeo Jun 12 '11 at 20:36
@Xeo: Removed that assertion to leave only the solution (or workaround, if you prefer). – Jon Purdy Jun 12 '11 at 21:02

score 0 · Answer 4 · answered Jan 01 '12 at 10:59

http://bytes.com/topic/c/answers/832994-shared_ptr-derived-classes-ambiguitity-overloaded-functions

struct yes_type { char dummy; };
struct no_type { yes_type a; yes_type b; };

template < typename From, typename To >
class is_convertible
{
    private:
        static From* dummy ( void );

        static yes_type check ( To );

        static no_type check ( ... );

    public:

        static bool const value = sizeof( check( *dummy() ) ) == sizeof( yes_type );

}; // is_convertible

An in boost's shared_ptr.h, change the constructor signature to:

template<class Y>
shared_ptr(shared_ptr<Y> const & r,
    typename enable_if<is_convertible<Y*, T*>::value, void*>::type = 0
    ): px(r.px), pn(r.pn) // never throws
{
}

C++0x Error: overloading a function with std::shared_ptr to const argument is ambiguous

4 Answers4

Linked