Question

Could anyone help me understand why the below code doesn’t compile (VS2010) when the getters are const ?

Here’s the test code:

#include <boost/system/error_code.hpp>

class socket {
public:

    // setter - throw exception version
void non_blocking(bool mode)
    {
        // ...
    }

    // getter - error code version      
    bool non_blocking(boost::system::error_code& ec) const
    {
        // ...
    }

    // setter - error code version
void non_blocking(bool mode, boost::system::error_code& ec)
    {
        // ...
    }

    // getter - throw exception version    
    bool non_blocking() const
    {
        // ...
    }
};

int main()
{
    socket s;
    boost::system::error_code ec;
    bool result = s.non_blocking(ec);

    return 0;
}

I know that boost::system::error_code is convertible to bool but can’t understand why the const cause the ambiguity. Here’s the error message from VS2010:

1>c:\projects\pcap++\trunk\main.cpp(145): error C2666: 'socket::non_blocking' : 2 overloads have similar conversions
1>          c:\projects\pcap++\trunk\main.cpp(134): could be 'bool socket::non_blocking(boost::system::error_code &) const'
1>          c:\projects\pcap++\trunk\main.cpp(129): or       'void socket::non_blocking(bool)'
1>          while trying to match the argument list '(boost::system::error_code)'
1>          note: qualification adjustment (const/volatile) may be causing the ambiguity

Answer 1

For the purpose of overload resolution, the parameter list of the two overloads are class socket &, bool and const class socket &, boost::system::error_code &.

The calling parameters are class socket &, boost::system::error_code &

To match the first overload, the following conversion is needed:

1.
class socket &              -> no conversion
bool                        -> user defined conversion
2.
class socket &              -> qualification conversion
boost::system::error_code & -> no conversion

In C++0x 13.3.3p1 :

Define ICSi(F) as follows:

— if F is a static member function, ICS1(F) is defined such that
ICS1(F) is neither better nor worse than ICS1(G) for any function G,
and, symmetrically, ICS1(G) is neither better nor worse than
ICS1(F); otherwise,

— let ICSi(F) denote the implicit conversion sequence that converts
the i-th argument in the list to the type of the i-th parameter of
viable function F. 13.3.3.1 defines the implicit conversion sequences
and
13.3.3.2 defines what it means for one implicit conversion sequence to be a better conversion sequence or worse conversion sequence than
another.

Given these definitions, a viable function F1 is defined to be a
better function than another viable function F2 if for all arguments
i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then

….

From this, we can see the neither of the match of the two overloads fits this requirement. For the one function, one conversion sequence is better and one conversion is worse than the corresponding conversion sequence of the other function, so the viable function cannot be determined.

If the second overload is not const, then the conversion sequence for the second overload does not need any conversion (both are identical), so this is better than the other overload, thus no ambiguity.