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