name lookup in derived class

[Jordan Taylor]

Hi, can anyone suggest how the compiler will decide which bar() to
invoke when we call d.dio()? I am getting the following output:

B foo
B bar

but is there a situation when the same code can print

B foo
D bar

?
#include<iostre am>
using namespace std;

class Base
{
public:
void foo()
{
cout<<"B foo"<<endl;
bar();
}

void bar()
{
cout<<"B bar"<<endl;
}
};
class Derived : public Base {
public:
void dio()
{
foo();
}
void bar()
{
cout<<"D bar"<<endl;
}
};
int main()
{
Derived d;
d.dio();
return 0;
}

[Phlip]

Jordan Taylor wrote:

Hi, can anyone suggest how the compiler will decide which bar() to
invoke when we call d.dio()? I am getting the following output:

B foo
B bar

but is there a situation when the same code can print

B foo
D bar

?

Is this homework?

The only situation is if you add 'virtual' to Base::bar().

In which case, this question becomes a textbook example of polymorphism.
Objects of type Base always call Base::bar(), Derived objects call
Derived::bar(), and objects that think they are Base but are really Derived
call Derived::bar().

This trick is most useful to decouple code, and limit the places you must
edit to upgrade code. Users of base classes needn't couple to derived class
behaviors.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Jordan Taylor]

Phlip wrote:

Jordan Taylor wrote:

Hi, can anyone suggest how the compiler will decide which bar() to
invoke when we call d.dio()? I am getting the following output:

B foo
B bar

but is there a situation when the same code can print

B foo
D bar

?
Is this homework?

I don't understand why every simple question gets tagged as homework.
Isn't there something called a "Beginner" anymore? Besides all colleges
are moving to Java so you shouldn't be so paranoid about homework
problems appearing. Just MHO

The only situation is if you add 'virtual' to Base::bar().

In which case, this question becomes a textbook example of polymorphism.
Objects of type Base always call Base::bar(), Derived objects call
Derived::bar(), and objects that think they are Base but are really Derived
call Derived::bar().
If d calls foo() does it morph into an object of type Base? My
understanding is that the scope of derived classes are nested. If
Derived inherits from Base, then Derived::bar() is also in the scope of
Base. Why doesn't the compiler let us use Derived::bar() then?

This trick is most useful to decouple code, and limit the places you must
edit to upgrade code. Users of base classes needn't couple to derived class
behaviors.
I'll look this up.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

thanks!

[Neelesh Bodas]

Jordan Taylor wrote:

If d calls foo() does it morph into an object of type Base? My
understanding is that the scope of derived classes are nested. If
Derived inherits from Base, then Derived::bar() is also in the scope of
Base. Why doesn't the compiler let us use Derived::bar() then?

The object doesnot get morphed, but the call is resolved at compile
time itself, since the function is not virtual. In other words, since
base::bar() is not virtual, any call to base::bar() is "early-bound",
or resolved at compile time. Had base::bar() been virtual, the binding
would have been delayed till run time, in which case the derived::bar()
would have been called if the function was invoked on an instance of
derived class.