🚀 go-pugleaf

Hi,

2 weeks ago I posted about a problem I had with
my c++ compilation. Here is the summary of what I
received as answers.

0 The original question: (with the correction)
-----------------------

	I have 4 classes: SA
			  SB subclass of SA
			  A
			  B  subclass of A

	class SA				class A
	{					{
	public:					}
	void F (A PAR);
	}

	class SB : public SA			class B : public A
	{					{
	public:					}
	void F (B PAR);
	}

	So SB redefines the F function defined in SA but the parameter
	type of SB:F is B a subtype of the parameter of SA::F.

	The bodies of theFs are: 
	void SA::F (A PAR) { cout << "F of SA" << endl; }
	void SB::F (B PAR) { cout << "F of SB" << endl; }
	// was void SB::F (B PAR) { cout << "F of SA" << endl; }

	And my main is:
	Main () {

	sa osa;			// line 1
	sb osb;		 	// line 2
 
	a oa;			// line 3
	b ob;			// line 4
 
	osa.f(oa);		// line 5
	osa.f(ob);		// line 6
 
	osb.f(oa);		// line 7
	osb.f(ob);		// line 8
	}


	When I compile with a ATT c++ compiler I get the following message:
	"E#669 cannot make a structure B from a A" for the line 7.

	But when I compile with g++ version 2.4.5 it compiles and this
	is the output:
	f of sa		// call of line 5
	f of sa		// call of line 6
	f of sa		// call of line 7
	f of sb		// call of line 8
	Which means that the call of F on an object of type SB with
	a parameter of type A calls the F of SA.

	I agree with the first policy (the ATT c++ compiler).

	My questions are:
	- which policy is the correct one? the ATT c++ one or the g++ one?
	- is there a bug in g++?
	- is there a bug in the ATT c++ compiler?
	- what the standard recommends?

I Bug in gcc?
------------

	According to the Annotated C++ Ref Manual SB::F(B) hides
	SA::F(A) but not overloads it. 
	
	Joern Sierwald <Sierwald@tu-harburg.d400.de>
	>
	> cfront is right here.
	> SB:F( B ) must _HIDE_ SA::F( A ), not OVERLOAD SA::( A ).
	>
	> I recommend that you read the Annotated C++ Reference Manual by Ellis.
	> I don't have it handy, but it says just that.
	>
	> It is a gcc bug, then.
	>
	> J"orn

	Allan Engelhardt <ENGELHARDT@AL0VSD.cern.ch> wrote my example and
	compiled it using the DEC c++ compiler and get the same result than
	the AT&T compiler. He wrote:
	>
	> Well, SB::F(B)  *hides*  the  SA::F(A)  function rather than 
	> overloading it (see the ARM 13.1). This means that line 7 will not work 
	> and the AT&T compiler message makes sense.
	>
	But he is also wandering if line 6 should compile or not.

	Werner Benger (werner@ast1.uibk.ac.at)
	>
	> The ATT C++ compiler is correct. Function SA::f(A) is hidden 
	> by SB::f(B).

	Bowden Wise <wiseb@cs.rpi.edu>:
	>
	> The reason why 
	>   osa.F(ob);
	> works is because, the compiler performs implicit conversion from a
	> derived class (B) to a base class (A).  This is because any base class
	> is a subpart of a derived object.  However, there is no way to
	> convert a base class to a derived class.   Consider this, a base class
	> could be used in more than one derived class.  The compiler has no way
	> of knowing which derived class the base class originates from. 
	> So, this is not allowed:
	>  osb.F(oa);

	Robert Nicholson <robert@steffi.demon.co.uk> compiled the example
	with gcc2.5.0 and got the same result than the AT&T compiler.

	Werner Benger, Robert Nicholson
	recommended me the latest version of g++ 2.5.2.

II Bug in the AT&T compiler?
--------------------------

	Martin v.Loewis <loewis@cs.tu-berlin.de>:
	> 
	> first note that I have neither read the ARM nor any ANSI C++ draft
	> in order to answer your question.
	> Consider the following case
	> 	class SC{
	> 		public:
	> 		void F(A PAR);
	> 		void F(B PAR);
	> 	};
	> As you know, this is valid C++. If you do now
	> 	SC osc;
	> 	osc.F(oa);
	> 	osc.F(ob);
	> then in the first case F(A) gets invoked, and in the second F(B).
	> This is due to function overloading.
	> 
	> In your example, the question is now:
	> Is the declaration of F(B) in class SB a redefinition of F in
	> class SA, or is it just an overloading?
	> As the SC sample shall convince you, F(B) is just another overloading
	> of the function name F, and therefore does not hide the definition of
	> F in class SA.
	> When calling osa.F(oa) and osb.F(ob), everything is obvious.
	> Now consider osa.F(ob). There is only a single declaration of F in
	> SA, so if any call is possible, the compiler must convert ob into
	> an A object. Fortunately, this is possible since B is subclass of A.
	> Now consider osb.F(oa). There are two definitions of F in SB. That
	> one which matches is A::F(A).
	> As you can see, g++ is right. Look at the version of CC in order
	> to find out if your compiler is just a bit dated.	

	Both my AT&T and g++ compilers accepts this as well.
	This example is valid but unfortunately it is different than mine.

	Leif Lonnblad <lonnblad@surya11.cern.ch>:
	>
	> Well, not having the ARM handy I would guess that gcc is right, in any
	> case I tend to agree with that policy. If class SB 'is a' SA it should
	> be able to inherit SA::F(A), if that for some reason isn't what you
	> want, you can get the AT&T behavior by introducing an empty private
	> member function SB::F(A) and gcc will 'hopefully' give you an error
	> message.

III Bug everywhere?
------------------

	Ivan Chow <chow@gluon.ssc.gov>
	>
	> According to my understanding of C++,
	> (since there is no ANSI C++ yet, I don't have a good
	> authority to quote)
	> 
	> class A {
	> };
	> 
	> means there is no public attribute of class A.
	> (C++ always have to explicitly declare public attributes)
	> therefore,
	> 
	> class B : public A {
	> };
	> 
	> is invalid.  (I think it is a good practice to put
	>   ; at the end.)
	> 
	> So the ATT C++ compiler is reporting an "correct" error.
	> 
	> I think
	> 
	> osa.f(ob);
	> 
	> should give you an error
	> because osa should not expect such a call.
	> Therefore, in my opionion,
	> both ATT C++, g++ has a bug here!

MY Conclusion
-------------

	This conclusion is mine and as there is no standard yet I hope I am right!

	F(B) of SB hides F(A) of SA but does not overloads it.
	ie F(A) of SA is not seen but it exists.
	ie OSB.F(OA) is illegal but OSB.SA::F(OA) is legal.
	ie OSB.F(OA) would have been legal is F(B) was not defined in SB.
	
	I did get the g++ 2.5.2 and checked all this with it and the
	AT&T compiler.

I would like to thank all the persons tha replied to my 
question, and sorry if I missed somedoby's reply.

-- 
Arash Khodabandeh,

  CERN ECP, Programming Techniques Group, CH-1211 GENEVE 23,
  Phone: + 41 22 767 8072, Fax: + 41 22 767 8730,
  Email: Arash.Khodabandeh@cern.ch khoda@ptsun00.cern.ch, akhodaba@dxcern.cern.ch.