🚀 go-pugleaf

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?

In Section 13.1 (page 311) of the Annotated C++ Reference Manual by
Ellis and Stroustrup there is an explanation of cfront's hiding
behavior and a rationale for it.  The basic idea is that many
programming styles result in fairly deep derivation trees, with the
base and derived types scattered liberally through the program.  In
such a program, it can be difficult to keep track of all of the
overloaded functions and thus it would difficult to determine the
consequences of adding another overloaded function if this hiding did
not occur.

This restriction is not as onerous as it might be -- your example
shows one way to get around it.  Of course, this word-around can
get tedious if you have classes with lots of overloaded member
functions.  One possibility would be to allow the programmer
to specify the g++ semantics as follows:

	class A {
	public:
	  void f(int);
	};
	
	class B : public friend A {
	public:
	  void f(char*);
	};
	
	main()
	{
	  B x;
	  x.f(3);
	}

The ``friend'' keyword in class B's base class list would tell
the compiler that B's scope should include that of A, so that
``x.f(3)'' would find A::f.

What do you think?
					Thanx, Paul