12

Possible Duplicate:
Why do multiple-inherited functions with same name but different signatures not get treated as overloaded functions?

This fails to compile in the indicated place with g++ 4.6.1:

enum Ea { Ea0 };
enum Eb { Eb0 };

struct Sa { void operator()(Ea) {} };
struct Sb { void operator()(Eb) {} };
struct Sbroken : Sa, Sb {};

struct Sworks {
    void operator()(Ea) {}
    void operator()(Eb) {}
};

int main() {
    Sworks()(Ea0);
    Sbroken()(Ea0); // g++ can't disambiguate Ea vs. Eb
}

Clang 2.8 does compile this code, which makes me uncertain if the code is really valid C++ or not. I was about to conclude optimistically that clang was right and g++ was wrong, but then I made a small change which made clang have a similar error:

enum Ea { Ea0 };
enum Eb { Eb0 };

struct Sa { void f(Ea) {} };
struct Sb { void f(Eb) {} };
struct Sbroken : Sa, Sb {};

struct Sworks {
    void f(Ea) {}
    void f(Eb) {}
};

int main() {
    Sworks().f(Ea0);
    Sbroken().f(Ea0); // both clang and g++ say this is ambiguous
}

The only change I made there was to use a named function f rather than operator(). I don't see why this should even matter, but it does: this version does not compile with g++ nor with clang.

Community
  • 1
  • 1
John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • 1
    Can you look at the code `clang` generates to see if it did anything sensible? – wallyk Nov 10 '11 at 17:17
  • 2
    Comeau's compiler (which is pretty standards compliant) also fails on your first snippet with an ambiguity error. – wkl Nov 10 '11 at 17:21
  • Answer: from N3242: 13.3.1.1.2 Call to object of class type [over.call.object]/1 "_The function call operators of `T` are obtained by ordinary lookup of the name `operator()` in the context of `(E).operator()`._" thus `Sbroken()(Ea0)` is interpreted as `Sbroken().operator(Ea0)`. The behaviour is the same as the one for ordinary member functions, which is described in the "**possible** duplicate" question. – curiousguy Nov 20 '11 at 11:08

2 Answers2

5

I think it has something to do with hiding the function(s) in the base classes, and the GCC's error message doesn't seem to help much, even if you use struct instead of enum : In fact, the error message is misleading, because now Ea and Eb are two different classes, with no implicit conversion from Ea to Eb, the ambiguity shouldn't arise, but GCC seems to disagree with me : http://ideone.com/cvzLW (see the modification also).

Anyway, if you bring the functions in the class scope, explicitly by writing using as:

struct Sbroken : Sa, Sb 
{
   using Sa::operator();
   using Sb::operator();
};

then it works : http://ideone.com/LBZgC

Same with other example as well:

struct Sbroken : Sa, Sb 
{
   using Sa::f;
   using Sb::f;
};

Code : http://ideone.com/3hojd

Nawaz
  • 353,942
  • 115
  • 666
  • 851
4

Trying to understand the actual text in the standard (§10.2) isn't easy, but there is an example which makes it clear: name lookup for a name x in the derived class fails if the name isn't present in the derived class, but it is present in more than one base class, and it isn't hidden. (Hidden isn't relevant here, as it only intervenes when virtual inheritance is present.) As far as I can tell, this is the case regardless of the name of the member; I can find no exception if the member happens to have the special name operator(). Overload resolution doesn't come into play, because their is failure in the name lookup, before the overload set is completely built. I'm pretty sure that both snippets of code are illegal, and that there is a bug in clang.

You can use using declarations to inject the names into the derived class, or you can explicitly define forwarding operators in the derived class. Once the name is found in the derived class, the compiler stops, and does not look in the base classes.

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • If a program is ill-formed and not required to emit a diagnostic wouldn't clang be quite within it's rights to emit some broken code? – Flexo Nov 10 '11 at 18:42
  • @awoodland I don't see anything in the standard which says undefined behavior. A diagnostic is required. (Once the diagnostic has been emitted, of course, the compiler can do anything it pleases.) – James Kanze Nov 10 '11 at 19:42
  • "_I can find no exception if the member happens to have the special name operator()_" function call is defined in term of `.operator()`. – curiousguy Nov 20 '11 at 11:35