Why a member function will override an free function with the samename even if the arguments does no

[Peng Yu]

Hi,

The following code doesn't work at the commented line. I'm wondering
why C++ grammar is defined this way. Shouldn't C++ be smarter enough
to figure out whether an member function or a free function shall be
used?

Thanks,
Peng

#include <iostream>

struct A {
A(int a) : _a(a) { }
int _a;
};


void doit(const A &a) {
std::cout << a._a << std::endl;
}

struct B {
public:
B(const A &a) : _a(a) { }
void doit() {
doit(_a);// the member function is conflicted with the free
function.
}
private:
A _a;
};


int main () {
B b((A(2)));
b.doit();
}

 

[peter koch]

Hi,

The following code doesn't work at the commented line. I'm wondering
why C++ grammar is defined this way. Shouldn't C++ be smarter enough
to figure out whether an member function or a free function shall be
used?

Thanks,
Peng

#include <iostream>

struct A {
    A(int a) : _a(a) { }
    int _a;

};

void doit(const A &a) {
  std::cout << a._a << std::endl;

}

struct B {
  public:
    B(const A &a) : _a(a) { }
    void doit() {
      doit(_a);// the member function is conflicted with the free
function.
    }
  private:
    A _a;

};

int main () {
  B b((A(2)));
  b.doit();

Because the standard says so. Actually, I also believe that this is a
good solution. The alternative would be to look all possible functions
up and choose the best candidate, but that easily becomes obscure in
some cases.
If you want to call a global function, all you have to do is to scope
the name as (here) ::doit.

/Peter

 

[James Kanze]

Because the standard says so. Actually, I also believe that
this is a good solution. The alternative would be to look all
possible functions up and choose the best candidate, but that
easily becomes obscure in some cases.

More than obscure, it's fragile. Someone adds an unrelated
function to a header file, and suddenly, your code unexplainedly
stops working. Presumably, if you have provided a member
function, that's the one you want to call. (I'm not even sure
that ADL kicks in if there is a member function. I rather hope
not.)

 

[Salt_Peter]

Hi,

The following code doesn't work at the commented line. I'm wondering
why C++ grammar is defined this way. Shouldn't C++ be smarter enough
to figure out whether an member function or a free function shall be
used?

Absolutely not, name lookup is strictly defined by the standard in
such a way that ambiguity and loose lookups are not allowed (it gets
quite complicated / involved too). The point here is that regardless
which compiler, architecture or platform you run the program in, no
loose interpretations of the standard causes side-effects or varied
results.
Keep it simple and secure. That *is* smarter.
Case in point, you have a program with 10K lines of code, once you
learn how to decypher name lookup diagnostics, correcting the issue is
childs play. With loose lookups: forget it. You would probably not
even be aware that in fact an error occurred.

 

[peter koch]

More than obscure, it's fragile.  Someone adds an unrelated
function to a header file, and suddenly, your code unexplainedly
stops working.  Presumably, if you have provided a member
function, that's the one you want to call.  

And if you don't, it is very easy to tell the compiler otherwise. This
is a very good example.

(I'm not even sure
that ADL kicks in if there is a member function.  I rather hope
not.)

I believe not, but as I have recently changed pc, I don't have my
draft standard ready.

/Peter