🚀 go-pugleaf

Sorry for the long quote.

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.  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