Re: Who is right [was Re: error: parameter may not have variably
modified type]
On Oct 22, 8:31 am, Helmut Jarausch <jarau...@igpm.rwth-aachen.de>
wrote:
Victor Bazarov wrote:
Helmut Jarausch wrote:
Victor Bazarov wrote:
...
Can anybody throw some light on this error?
We can. And to help us help you you should start by
reading the FAQ, especially the section 5.
Here is a small but complete example to show the problem.
See the last 4 lines.
[..valid code redacted..]
Comeau online trial compiles your code without a problem.
Obviously there is something wrong with the compiler you are
using. Try contacting the maker[s] of it, upgrade it,
downgrade it, or/and even post to the newsgroup dedicated to
that compiler.
I've created a bug report for gnu.gcc and the answer was
I don't think this is misparsing this at all. This is one
place in the C++ standard that says it should be parsed as a
function declaration rather than a variable declaration to
resolve an ambiguous between those two.
So, who is right? Whom to ask next?
In a certain sense, it doesn't matter. The authors of g++ are
more or less gods when it comes to their compiler, and if they
decide on one particular interpretation, and you have to use
g++, you're stuck with it, even if it doesn't make sense or is
manifestly wrong.
And if it's a function declaration, indeed, how to tell the
compiler that I wish a variable declaration?
Here the questionable code again (see the last few lines, first)
[...]
form proj (space(V[i]), V_new_i, "mass");
/* error: parameter may not have variably modified type
'space [(((long unsigned int)(((long int)i) + -0x00000000000000001)) +=
1)]'
*/
First, there is absolutely no way that proj can be interpreted
as a function declaration; the string literal prevents that,
regardless of anything else. Second, if "space" is the
name of a type (as it is in your code), =BBspace(V[i])=AB is a
function declaration in any context that allows function
declarations. The only contexts which allow declarations
other than at the statement level, however, is as part of other
declarations; the only context in which a function declaration
can be followed by a comma is as a parameter in another function
declaration. Since in this case, the string literal means that
this statement cannot be a function declaration, =BBspace(V[i])=AB
cannot be a parameter declaration, and thus, cannot be a
function declaration. There's no ambiguity. (This is a
difficult parse, however, since the interpretation here depends
on context. In something like:
form proj( space(V[i]) );
=BBspace(V[i])=AB is a function declaration, and the entire
statement is a function declaration, because there is nothing
which makes it illegal as a function declaration.)
I do remember earlier versions of g++ (2.95.2?) having problems
with this; they didn't consider context to the right of the
expression when making the decision, so something like:
form proj( space(V[i]), "abc" );
would fail to compile, treating =BBspace(V[i])=AB as a function
declaration, whereas:
form proj( "abc", space(V[i]) );
worked, since the preceding string literal had removed the
ambiguity of the context. Later versions of g++ fixed this. It
sounds to me like they've reintroduced the bug, and that someone
has decided (on what grounds, I don't know), that it's not a
bug, but a feature.
At any rate, when in doubt, it never hurts to put an extra set
of parentheses around the expression, i.e.:
form proj( (space(V[i])), V_new_i, "mass" );
There is no syntax in which a declaration begins with an opening
parentheses. (Note that you need the extra parentheses; the
first opening parentheses are part of the outer declaration
here.)
--
James Kanze