Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!portal!cup.portal.com!wmmiller
From: wmmiller@cup.portal.com (William Michael Miller)
Newsgroups: comp.lang.c++
Subject: Re: More ZOrtech c++
Message-ID: <32038@cup.portal.com>
Date: 25 Jul 90 00:15:23 GMT
References: <1990Jul23.161817.23460@watserv1.waterloo.edu>
Organization: The Portal System (TM)
Lines: 44

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.

This should go into the "frequently asked questions" file, if it has not
already.  This is discussed in more detail in E&S section 13.1, especially
page 311, but the short answer is that a derived class is a separate scope
from the base class, and you only look in the base class for a match if
you can't find one in the derived class.

There's good justification for this rule.  Consider the following case:

         struct B {
            foo(char*);
            };
         struct D: B {
            foo(short);
            };
         D d;
         d.foo(1);

This resolves to D::foo(short).  Now you get a new release of the library
that defines B and somebody has had the bright idea of adding B::foo(int).
Under the "intuitive approach" you mentioned, your code stops working
because d.foo(1) now resolves to B::foo(int), not to your D::foo(short).
Under the current definition, your program continues to work because any
D::foo() hides all the B::foo()s, regardless of argument type.  If you want
to make a B::foo() available to consumers of D, it's very easy:

         struct D: B {
            foo(char* cp) { return B::foo(cp); }
            };

It doesn't even add any execution overhead.  I think the potential nasty
surprise factor of the "intuitive approach" completely outweighs the minor
inconvenience of requiring forwarding functions.

------------------------------------------------------------------------------
William M. Miller, Glockenspiel, Inc.; P. O. Box 366, Sudbury, MA 01776-0003
wmmiller@cup.portal.com         BIX: wmiller            CI$: 72105,1744