Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!decwrl!ucbvax!galileo.berkeley.edu!jbuck From: jbuck@galileo.berkeley.edu (Joe Buck) Newsgroups: comp.std.c++ Subject: Re: Inheritance in cfront and g++ Message-ID: <38219@ucbvax.BERKELEY.EDU> Date: 17 Aug 90 18:14:07 GMT References: <1990Aug17.141710.5004@aucs.uucp> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: jbuck@galileo.berkeley.edu (Joe Buck) Distribution: comp Lines: 50 Sorry for the long quote. In article <1990Aug17.141710.5004@aucs.uucp>, 880716a@aucs.uucp (Dave Astels) writes: |> In article fox@allegra.att.com (David Fox) writes: |> >In porting code from g++ to cfront I have come across the following |> >inconsistancy. The following program compiles as-is in g++ |> > |> > class A { |> > public: |> > void f(int); |> > }; |> > |> > class B : public A { |> > public: |> > void f(char*); |> > //void f(int i) {A::f(i);} |> > }; |> > |> > main() |> > { |> > B x; |> > x.f(3); |> > } |> > |> >And the call to x.f(3) finds the function f in class A. In |> >cfront, however, the function f in class B "masks" the f in |> >class A, so you need the commented f(int) member function to |> >get this to compile. 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. -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck