Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!brunix!sdm
From: sdm@cs.brown.edu (Scott Meyers)
Newsgroups: comp.lang.c++
Subject: Re: More ZOrtech c++
Keywords: overloading, inheritance, zortech
Message-ID: <45655@brunix.UUCP>
Date: 24 Jul 90 16:23:32 GMT
References: <1990Jul23.161817.23460@watserv1.waterloo.edu>
Sender: news@brunix.UUCP
Reply-To: sdm@cs.brown.edu (Scott Meyers)
Distribution: comp
Organization: Brown University Department of Computer Science
Lines: 28

In article <1990Jul23.161817.23460@watserv1.waterloo.edu> pdevries@watserv1.waterloo.edu (Peter DeVries) writes:
| I REALLY don't understand this. Walter replied to this problem that it is
| NOT a compiler bug. That declaring SetSomething(int,double) in the derived
| class hides ALL inherited declarations of SetSomething, INCLUDING overloaded 
| ones.
| 
| SAY WHAT?  This goes against any common sense that I may have. Why would 
| overloaded functions work so differently than the intuitive approach. (ie.
| as inheritance usually works). The function name is completely different since
| the parameters are of different types, so why would one function in the derived
| class have any affect on accessing the other ones?
| 
| By the way, it will call B.SetSomething(int,double) even if I explicitly cast
| the value to a LONG.

This is the way the language is defined to work. It's counterintuitive,
yes, but it was defined to work this way to keep you from accidently
inheriting functions from libraries with signatures that would cause the
"wrong" (from your point of view) function to be called.  The same
rationale results in the fact that access restrictions are not taken into
account when disambiguating calls to multiply inherited function names, an
oddity that is arguably even more unintuitive.  

If this goes against any "common sense" you may have, think about it again
in the context of software engineering and you may find that your common
sense changes.

Scott