0

This code compiles (Using GCC / C++11):

void doStuff_HELPER(int a) { /**/ }

class SomeClass{

public:
    void doStuff() {doStuff_HELPER( 10);}

};

This doesn't:

void doStuff(int a) { /**/ }

class SomeClass{

public:
    void doStuff() {doStuff( 10);}

};

It doesn't say it's ambiguous or it can't be overloaded or anything it just says: "no matching function SomeClass::doStuff(int)", "candidate: void SomeClass::doStuff()". Is this the correct behavior? What does the standard say about this?

(Also, what is the best practice for such helper functions? Should they be put into a separate namespace maybe?)

AdyAdy
  • 988
  • 6
  • 19
  • 2
    The compiler is correct, the function call is resolved using [unqualified name lookup](http://en.cppreference.com/w/cpp/language/overload_resolution) ([see here for example](https://stackoverflow.com/questions/11696029/why-class-member-functions-shadow-free-functions-with-same-name)). Both the free function and class method are reachable and valid lookups. – Cory Kramer Feb 15 '18 at 20:46
  • 6
    `::doStuff(10);` is not ambiguous. Neither is `this->doStuff(10);` - if you name things in different scopes the same you have to help the compiler figure out which function you mean. The easy solution is to just not use the same name. The alternative is to explicitly tell the compiler which one you want to call. – Jesper Juhl Feb 15 '18 at 20:47

2 Answers2

3

Call it explicitly specifying scope: ::doStuff(10);

user7860670
  • 35,849
  • 4
  • 58
  • 84
2

You should use the Scope Resolution Operator to resolve this. Using ::doStuff(10) instead of doStuff(10) tells the compiler to look in the global namespace to resolve the name collision.

Jeff Melton
  • 357
  • 4
  • 13