Re: [lmi] gcc-3.3 error?

[Vadim Zeitlin]

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