Overloading/Inheritance issue

[Steve Schveighoffer]

Regan Heath Wrote:

> 
> It's truly odd that no-one seems to have a problem with it in C++.  It's 
> not as if C++ even has 'alias' so it cannot pull symbols in, you're left 
> re-implementing in the derived class.  Perhaps everyone just does that 
> without thinking about it.

After thinking about it, my opinion is that C++ coders tend to avoid implementing everything in objects using inheritance as opposed to languages which require using objects for everything (i.e. Java).  This tends to have many coders putting their "methods" in the global namespace instead of in a method, putting everything in the same scope.

and BTW, Walter in his previous posts rightly points out that the "using" keyword can be used inside a C++ class much like the "alias" keyword is used in a D class to achieve the same effect.

> 
> > However, I think it should be changed.  Not sure if it will, as it
> > seems there  is already a precedent.  In my opinion, the base class
> > should be examined if the derived class does not provide a suitable
> > match.  I can't see how this would cause too much of a performance
> > hit
> 
> Performance isn't the reason against the Java behaviour, here is Walters 
> explaination:
> 
> <quote Walter quoting Stroustrup>
> ...
> </quote>
> 
> So, as you can see it's not for performance reasons but rather to avoid 
> obscure bugs which when they manifest do so silently.
> 
> Regan

My argument is not against this, as you will note that in these examples, both base and derived classes can match the call by some sort of implicit conversion.  In the case where both the base class and the derived class  match the call, I could care less if the derived class was called instead of the base class.  Who can say what class documentation the coder was looking at when he wrote the call?  Both options seem equally likely.

I am proposing a change of behavior when the derived class CANNOT match the call.  At that point the compiler errors out instead of examining the base classes.  When the coder writes code where there is only one match, and that match is in a base class, it makes perfect sense that the coder explicitly wants to call the base class' method.  I see no reason to force the coder to explicitly call for the base class' method when there is no alternative in the derived class, the code is unambiguous.

I'd bet we'd see 0 obscure bugs if this change was made ;)  As I've mentioned, I've already seen one obscure bug caused by the current implementation...

-Steve