When you call a.foo();, the compiler goes through overload resolution to find the best function to use. When it builds the overload set it finds void foo() const and void foo() Now, since a is not const, the non-const version is the best match, so the compiler picks void foo(). Then the access restrictions are … Read more
Look at the error message from gcc: a.cpp:16: error: call of overloaded ‘function(double, double)’ is ambiguous a.cpp:3: note: candidates are: void function(int, int) a.cpp:9: note: void function(float, float) A call to either function would require truncation, which is why neither is preferred over the other. I suspect you really want void function(double y,double w). Remember … Read more
As far as I know non-template function is always preferred to template function during overload resolution. This is true, only when the specialization and the non template are exactly the same. This is not the case here though. When you call uct u3(u1) The overload sets gets uct(const uct &) uct(uct &) // from the … Read more
I don’t have a quote from the standard, but cppreference confirms my suspicions: A non-class non-array prvalue cannot be cv-qualified. (Note: a function call or cast expression may result in a prvalue of non-class cv-qualified type, but the cv-qualifier is immediately stripped out.) The returned const int is just a normal int prvalue, and makes … Read more
It’s obvious to us which function you intend to be chosen, but the compiler has to follow the rules of C++ not use clever leaps of logic (or even not so clever ones, as in simple cases like this!) The relevant constructor of std::function is: template<class F> function(F f); which is a template that accepts … Read more
Converting to a std::string requires a “user defined conversion”. Converting to void const* does not. User defined conversions are ordered behind built in ones.
Looks like this is mentioned in the C# specification 5.0, 7.5.3 Overload Resolution: Overload resolution selects the function member to invoke in the following distinct contexts within C#: Invocation of a method named in an invocation-expression (§7.6.5.1). Invocation of an instance constructor named in an object-creation-expression (§7.6.10.1). Invocation of an indexer accessor through an element-access … Read more
Which function from an overload set is chosen to be called (i.e. overload resolution) depends (in part) on how many arguments of the function call must go through an implicit conversion, and what kind of conversion is needed. The rules that are relevant to your example are: For each pair of viable function F1 and … Read more
“Hello World” is a string literal of type “array of 12 const char” which can be converted to a “pointer to const char” which can in turn be converted to a bool. That’s precisely what is happening. The compiler prefers this to using std::string‘s conversion constructor. A conversion sequence involving a conversion constructor is known … Read more
The fundamental reason for this (standard-conforming) ambiguity appears to lie within the cost of conversion: Overload resolution tries to minimize the operations performed to convert an argument to the corresponding parameter. An array is effectively the pointer to its first element though, decorated with some compile-time type information. An array-to-pointer conversion doesn’t cost more than … Read more