Re: c++/1924

Re: c++/1924

[Joe Buck]

The following reply was made to PR c++/1924; it has been noted by GNATS.

From: Joe Buck <jbuck@synopsys.com>
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, lakshman@nssl.noaa.gov,
        John.Krause@nssl.noaa.gov, Kenny.Simpson@gs.com
Cc:  
Subject: Re: c++/1924
Date: Mon, 26 Feb 2001 15:16:55 -0800

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1924&database=gcc
 
 Thanks for the bug report.
 
 The problematic construct is
   C obj(B(A::getA(4)) , B(A::getA(5)), 3);
 
 where B and C are classes.
 
 Kenny Simpson points out the issue in C++ that certain constructs can be
 parsed as either constructor calls or function declarations, and that
 the C++ language rule is, when this occurs, that we call it a function
 declaration.  However, there's a problem in applying that thinking in
 this case: the construct in this example can *not* be parsed two ways:
 the third argument, the "3", makes sense only for a constructor call,
 it cannot be the declaration of an argument.  This means that the
 compiler
 needs to accept it as a constructor invocation.  So we do indeed have a
 bug.
 This bug is present both in 2.95.2 and current snapshots.
 
 This is a nasty case where correct C++ parsing requires unbounded
 lookahead,
 and is hard to fix.  Kenny's suggested workaround (adding parentheses)
 will work, though.  That is, writing
 
   C obj( ( B( A::getA(4)) ),
             B( A::getA(5) ),
             3 );
 
 -- 
 The reasonable man adapts himself to the world; the unreasonable man
 persists in trying to adapt the world to himself. Therefore, all
 progress
 depends on the unreasonable man.         -----George Bernard Shaw

Re: c++/1924

[Simpson, Kenny]

The following reply was made to PR c++/1924; it has been noted by GNATS.

From: "Simpson, Kenny" <Kenny.Simpson@gs.com>
To: "'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>,
	"'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>,
	"'lakshman@nssl.noaa.gov'" <lakshman@nssl.noaa.gov>,
	"'John.Krause@nssl.noaa.gov'" <John.Krause@nssl.noaa.gov>
Cc:  
Subject: Re: c++/1924
Date: Fri, 16 Feb 2001 19:42:41 -0500

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl
 
 I don't think that this is a bug.
 If the last statement were changed to:
   C obj( ( B( A::getA(4)) ),
            B( A::getA(5) ),
            3 );
 It compiles without diagnostic - as it should.
 
 (Paraphrasing Scott Meyers' lecture notes)
 In general:
 	C foo( B   ); // 1. foo is a function taking (an unnamed) B,
 returning a C
 	C foo( B a ); // 2. samething, parameter is named a
 	C foo( B(a)); // 3. same thing
 
 	C foo( B(f*)()); // 4. foo takes a pointer to a function taking no
 arguments, returning a B.
                        //    foo's function pointer parameter is named f
 	C foo( B f()  ); // 5. same thing (valid C++, invalid for C)
 	C foo( B ()   ); // 6. same thing - unnamed parameter
 
 So:
 	C obj( B( arg1 ), B( arg2 ) );
 Is saying "obj" is a function returning a C.
 The parameters for "obj" are arg1 and arg2.
 arg1 and arg2 are of type B.
 Just like case 3.
 
 The "extra" parens force the statement to be parsed as declaring obj as a C.
 (many compilers get this wrong)
 
 As far as the "type specifier omitted for parameter" goes,
 maybe it is parsing "B( A::getA(4))" as a parameter named "A::getA"
 that is a function returning a B and taking a parameter of type -
 4? - no type specified for parameter, parse error before numeric constant.
 
 -Kenny
 (Not speaking for my employer)