c++/2736: g++ misinterpreting initializer syntax

Phil Edwards pedwards@disaster.jaj.com
Fri May 4 15:36:00 GMT 2001


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

From: Phil Edwards <pedwards@disaster.jaj.com>
To: derrick@caltech.edu
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/2736: g++ misinterpreting initializer syntax
Date: Fri, 4 May 2001 17:13:22 -0400

 On Fri, May 04, 2001 at 11:39:22AM -0000, derrick@caltech.edu wrote:
 > >Release:        2.95.3
 > >Organization:
 > >Environment:
 > i686-pc-linux-gnu (RedHat 6)
 > >Description:
 > I have the following in an initializer list:
 > y(Range(6,7))
 > where y is a Blitz++ array.  g++ seems to be trying to 
 > interpret the Range(6,7) as a function call rather than
 > as a constructor for a Range object. . . it gives the
 
 Bad news and good news.  Sort of.
 
 Bad news:  I can't reproduce this using today's GCC 3.0 snapshot due to
 other errors, mostly namespace-related.  Note that 2.95.3 treated namespace
 std the same as the global namespace by design, so lots of little things
 could slip through.  With 3.x this is not the case, and so I get all kinds
 of errors about math functions and namespace std.
 
 Good news:  this looks like a long-standing well-known bug in the C++ parser.
 See <URL: http://gcc.gnu.org/bugs.html#known > and the "parse errors for
 simple code" section for similar examples.
 
 Basically there is an infamous ambiguity between declaring a variable with
 certain kinds of temporaries as constructor arguments, and declaring a
 function with possibly-unnamed arguments.  The C++ standard requires the
 compiler to go with the function declaration if it can't figure it out.
 See <URL: http://compilers.iecc.com/comparch/article/01-03-052 > for another
 example.
 
 If you try the workarounds in either of those URLs (e.g., redundant parens)
 and it works, please append a note to this PR so we can close it.
 
 
 Luck++;
 Phil
 
 -- 
 pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
 devphil at several other less interesting addresses in various dot domains
 The gods do not protect fools.  Fools are protected by more capable fools.



More information about the Gcc-prs mailing list