Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!usc!ucsd!ucbvax!bloom-beacon!eru!luth!sunic!tut!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.std.c++
Subject: Re: Inheritance in cfront and g++
Message-ID: <1990Aug20.115115.3646@tukki.jyu.fi>
Date: 20 Aug 90 11:51:15 GMT
References: <FOX.90Aug15101045@devo.allegra.att.com> <1990Aug17.141710.5004@aucs.uucp> <38219@ucbvax.BERKELEY.EDU>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Distribution: comp
Organization: University of Jyvaskyla, Finland
Lines: 59

In article <38219@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes:
>In article <1990Aug17.141710.5004@aucs.uucp>, 880716a@aucs.uucp (Dave
>Astels) writes:
>|> In article <FOX.90Aug15101045@devo.allegra.att.com>
>fox@allegra.att.com (David Fox) writes:
>|> >In porting code from g++ to cfront I have come across the following
>|> >inconsistancy. [...]

I.e. a function declaration in an inner scope hides all functions
with the same name declared in outer scopes, independently of
argument types. According to the Release 2.0 Ref.Man., Sc. 13.1,
this applies even to other cases than base class - derived class.

>|> [...]  To me, the g++ semantics make more sense.
>|> >Do others agree?
>
>> I feel as you do.  B::f(char *) shouldn't override A::f(int).
>> Unfortunately Zortech (2.06) doesn't aggree.  It works as cfront does.
>
>> I would think that overriding would take place using the mangled name.
>> Thus f(int) would be completely different than f(char *).
>
>Unfortunately, E&S (which is the base document for the standard) mandates
>the cfront behavior.  Unless this is changed, you can expect future
>versions of g++ to be changed to conform (since Michael Tiemann has
>promised to track the standard).
>
>Stroustrup justifies this by pointing out cases where the g++ behavior
>might lead to surprises when new functions are added, but I'm not
>swayed by his argument.

This is an unorthogonal kludge, which makes the rules
of a complicated language even more complicated.
As far as I can see, it is also a deviation from older language
specifications. Already the subtle difference between virtual
and non-virtual overloading can be surprising enough; we don't
need this hiding rule to bite us.

If there are enough special cases to warrant this kind of behaviour,
it should be declared with a new keyword, say "semipublic"
instead of "public" base class. In the non-class-related case,
the Ref.Man. example goes like this:
  int f (char *);
  void g ()
  {
    extern f (int);
    ...
  }
It would be more sensible if this implied only ordinary overloading,
and an additional keyword ('hide') should be used in those weird cases
where one really wants to hide all functions named 'f' in the outer scope.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)