🚀 go-pugleaf

Doug,

Allow me to post a follow-up to your follow-up on one of my recent G++
bug reports.  Your follow-up was as follows:

|In article <8903110137.AA08978@riunite.aca.mcc.com> rfg@MCC.COM (Ron Guilmette) writes:
|++ The following code gets an error using G++ 1.34.0/Sun3.  It shouldn't.
|++ 
|++ Cut here
|++ ------------------------------------------------------------------------
|++ /*
|++ Description - The c++ "manual" (p. 270) says that "... a declaration may add
|++ 		default arguments not given in previous declarations"  This
|++ 		privledge should probably extend to method declarations and
|++ 		function declarations alike.  The following code checks that
|++ 		a re-declaration of a method may add some new defaults.
|++ */
|++ 
|++ struct class1 {
|++ 	void method1 (int arg1, int arg2);
|++ 	void method1 (int arg1, int arg2 = 35);
|++ };
|++ ---------------------------------------------------------------------------
|++ g++  -S x06.cc
|++ x06.cc:11: `void class1::method1 (int, int (=  35 ))' is already defined in aggregate scope
|
|I'm not sure if G++ is wrong here.  Here's what cfront 1.2.1 sez:
|
|----------------------------------------
|CC  bug.c:
|"bug.c", line 12: error: two declarations of class1::method1()
|sorry, cannot recover from previous error
|1 error
|----------------------------------------
|
|This error certainly makes intuitive sense, although I can see how one
|might come to the other interpretation from the ``manual.''  I guess
|we'll just have to wait for 2.0 and the new C++ reference...

I believe that the "manual" (if you could call it that!) and my
interpretation are both correct, and that this *is* a bug.  I think
that the idea was to allow you to have one declaration of a method
or function then some calls to that method/function, then another
declaration of the method/function with more defaults, then some more
calls which may now make use of the added defaults.

This is definitely allowed for non-member functions (and is supported
by G++ 1.34.0 for such functions).  I think that in this case, the same
semantics should apply to both member and non-member functions.

// Ron Guilmette  -  MCC  -  Experimental (parallel) Systems Kit Project
// 3500 West Balcones Center Drive,  Austin, TX  78759  -  (512)338-3740
// ARPA: rfg@mcc.com
// UUCP: {rutgers,uunet,gatech,ames,pyramid}!cs.utexas.edu!pp!rfg