[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] gcc-3.3 error?
From: |
Vadim Zeitlin |
Subject: |
Re: [lmi] gcc-3.3 error? |
Date: |
Tue, 1 Nov 2005 19:31:05 +0100 |
On Tue, 01 Nov 2005 16:44:27 +0000 Greg Chicares <address@hidden> wrote:
GC>
http://savannah.nongnu.org/cgi-bin/viewcvs/lmi/lmi/calculate.hpp.diff?r1=1.11&r2=1.12
GC> // compilation workaround for g++ 3.3: passing
e_ledger_type(e_ill_reg)
GC> // directly to Ledger ctor results in an error (but the code
compilers
GC> // fine with g++ 3.4 and 4.0)
GC>
GC> Vadim--I don't have g++-3.3 installed. Would you please show me the
GC> error message it produces for preceding revision 1.11?
Here is the minimal sample demonstrating the problem:
1 enum e_val_type { e_val };
2
3 template <typename ET, int N>
4 struct xenum
5 {
6 xenum(ET v);
7 };
8
9 typedef xenum<e_val_type, 1> e_type;
10
11 struct Foo
12 {
13 Foo(const e_type& t, int n);
14 };
15
16 void func()
17 {
18 Foo f(e_type(e_val), 17);
19 }
And here are the results:
% g++-4.0 -fsyntax-only -Wall lmit.cpp
% g++-3.4 -fsyntax-only -Wall lmit.cpp
% g++-3.3 -fsyntax-only -Wall lmit.cpp
lmit.cpp: In function `void func()':
lmit.cpp:18: error: type specifier omitted for parameter
lmit.cpp:18: error: syntax error before numeric constant
% g++-3.2 -fsyntax-only -Wall lmit.cpp
lmit.cpp: In function `void func()':
lmit.cpp:18: type specifier omitted for parameter
lmit.cpp:18: syntax error before numeric constant
% g++-2.95 -fsyntax-only -Wall lmit.cpp
lmit.cpp: In function `void func()':
lmit.cpp:18: type specifier omitted for parameter
lmit.cpp:18: parse error before `17'
And, FWIW
[VC 6.0]$ cl /Zs /W4 lmit.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
lmit.cpp
$
[VC 7.1]$ cl /Zs /W4 lmit.cpp
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
lmit.cpp
$
GC> Similar constructs might be used elsewhere, perhaps in code you aren't
GC> building; if so, I'd like to consider fixing them all.
This doesn't contradict at all what you say here but if you do find some
file which I don't build, please let me know so that I could fix it.
GC> But first I'd like to understand the problem; do you see any reason why
GC> this should not be legal?
I don't, I think it's a compiler bug. It seems to misparse the line 18 as
a function declaration (hypothesis confirmed by the fact that it's enough
to take e_type(e_val) in an additional pair of brackets to make the error
disappear -- however I think such fix would be less clear than what I did).
Regards,
VZ