Inheritance, Overloading, and Candidate Lists

[Dan Noland]

I can work around this easily enough, but can someone help me
understand why this works as it does? It seems that functions from a
grandparent class are not available as candidates for overload
resolution in the grandchild class?

/***** Begin Example *****/
#include <iostream>

class Foo
{
public:
void somefunc(int a);
};

class Bar: public Foo
{
public:
void somefunc(int a, int b);
};

class Baz: public Bar
{
public:
void broken();
};

void Foo::somefunc(int a)
{
std::cout << "somefunc 1 arg: " << a << std::endl;
return;
}

void Bar::somefunc(int a, int b)
{
std::cout << "somefunc 2 args: " << a << ", " << b << std::endl;
return;
}

void Baz::broken()
{
int arg = 555;
// Foo::somefunc(arg); <-- This works
somefunc(arg); // <-- Why doesn't this work?
return;
}

int main(int argc, char** argv)
{
class Baz tmp;
tmp.broken();
return(0);
}

/***** Begin Example *****/

[Andre Kostur]

Dan Noland <no******@gmail.comwrote in news:1192212441.350855.171600
@y27g2000pre.googlegroups.com:

>
I can work around this easily enough, but can someone help me
understand why this works as it does? It seems that functions from a
grandparent class are not available as candidates for overload
resolution in the grandchild class?

/***** Begin Example *****/
#include <iostream>

class Foo
{
public:
void somefunc(int a);
};

class Bar: public Foo
{
public:
void somefunc(int a, int b);
};

class Baz: public Bar
{
public:
void broken();
};

See the C++ FAQ, section 23.9

http://www.parashift.com/c++-faq-lit....html#faq-23.9

[Dan Noland]

On Oct 12, 4:06 pm, Andre Kostur <[e-mail]:

Dan Noland <[e-mail] in news:1192212441.350855.171600
@y27g2000pre.googlegroups.com:

I can work around this easily enough, but can someone help me
understand why this works as it does? It seems that functions from a
grandparent class are not available as candidates for overload
resolution in the grandchild class?

/***** Begin Example *****/
#include <iostream>

class Foo
{
public:
void somefunc(int a);
};

class Bar: public Foo
{
public:
void somefunc(int a, int b);
};

class Baz: public Bar
{
public:
void broken();
};

See the C++ FAQ, section 23.9

http://www.parashift.com/c++-faq-lit....html#faq-23.9

Thanks, I just found a similar explanation in section 19.3.1 of
Lippman and Lajoie. It seems strange that the shadowing is done by
function name rather than function prototype, but this works. Do any
language/compiler gurus know why this is the case?

YT,
Dan Noland
http://nolandda.org/

[mcostalba]

On 12 Oct, 22:18, Dan Noland <[e-mail]:

>
Thanks, I just found a similar explanation in section 19.3.1 of
Lippman and Lajoie. It seems strange that the shadowing is done by
function name rather than function prototype, but this works. Do any
language/compiler gurus know why this is the case?

YT,
Dan Nolandhttp://nolandda.org/

It's a safety measure against very difficult bugs.
Suppose you are using your preferred library in your project. This
library has a very deep and complex hierarchy, you create your class
subclassing from a class of this library:

class myclass : dialog_box
{

.... cut ...

void clear(long id);

};

Now suppose that somewhere in the library there is a class widget and
dialog_box is derived from that.
class widget
{

.... cut ...

void clear(int id);

};
and *you are not aware of the exsistance of widget::clear()* it can
happen in very big libraries, as example GUI libraries.
Now somewhere in your code you write:

myclass c;
c.clear(7);

Q: what member do you think compiler will call?

A: a conforming compiler will call _fortunatly_ your myclass::clear()
function, but if the hidden rule was not present the compiler would
have called widget::clear() instead.

If you don't know about widget::clear() finding the bug could span
from difficult to nightmare!

Proably who introduced such a rule in C++ was bitten by something like
this ;-)