pure virtual functions and name injection

[John Love-Jensen]

Hi Pierre,

> I agree, but what surprised me is that it is necessary. I have a long
> experience with C++, and it is the first time that I do not
> understand why it can't resolve a name.

The name (with a different signature) in the child class obscures the name
in the parent class.

The language does not provide the kind of "implicit overloading" you were
relying.  It's a safety feature, such that if you add a function to the
parent class that already had the same name in a derived class, varying only
in signature, that you are aware of the potential error.

The using directive can be used to pull the name forward.

> But gcc internally use name mangling according to the prototype,
> right ? So that I would have expect a real call to foo() to be
> explicit enough to resolve.

It's not a name mangling issue.

It's a visibility issue.

Child class b is hiding the name that is present in parent class a.

> Certainly, but in this case, I was rather expecting a compile error,
> claiming that the pure virtual method had no body. On the contrary,
> gcc has accepted it, so that I thought that it has found the right foo
> () !

You can have pure virtual methods that provide a body.  That's useful if
you'd want to provide the functionality for the pure virtual because it does
the right thing in the general case, but the derived classes can still
override it for their particular cases.

You still have to override the function in the child class.  You invoke the
parent method just as you did:  a::foo()

HTH,
--Eljay