another g++ compilation error without any sense

Question

So, I'm still working on this big project to make it compiles on Linux. So, again, I got some error that shouldn't be allow to exist.

Here's some error that I got:

(1) error: expected identifier before numeric constant
(2) error: "Value" doesn't name a type

Here's a sample piece of code, simplified, that show you where I get those errors:

class Test
{
public:
  enum Value
  {
    V1 = 0,  // error (1) is here
    V2 = 1,
    V3 = 2
  };

private:
  Value value; // error (2) is here

public:
  // constructor and other function
};

Also, that piece of code is valid in some part of the project. But it's not in other parts. I did everything, I rename stuff to be sure it was not ambiguous, doesn't change anything.

Stuck with GCC 4.1.2

Check the preprocessor output. There's clearly a macro `V!` defined somewhere. — James Kanze, May 24 '12 at 14:15
I heard people telling me that their compiler is stupid many times already. I have to say that in the end it was never the compiler to blame. — ypnos, May 24 '12 at 14:16
Does the example code provokes an error ? If not, then we need a piece of code that exhibits the error to actually help you out. There is probably something else that you do not show here. You could try out running Clang or a higher version of gcc just to see if the diagnosis is better. — Matthieu M., May 24 '12 at 14:17
it's a 500 files project... it's a bit hard to show more code. — widgg, May 24 '12 at 14:17
@widgg - we don't want to see more code from your project. We want you to reduce a copy of your project to the smallest possible file that demonstrates the problem. I suspect that, during the reduction process, you will find the problem yourself. See http://sscce.org and [Machete Debugging](http://dev.rootdirectory.de/wiki/MacheteDebugging). — Robᵩ, May 24 '12 at 14:19
A lot... so, I #undef all the things in the enumeration to see what will happen... I will know in 20 minutes! (that header files is required in too much part of the project) — widgg, May 24 '12 at 14:19
I don't think the compiler is stupid... I think VC++ (the original compiler on Windows) allows to much stuff that it makes it incredibly hard to take the source and compile it on Linux. VC++ is like stupid proof, so it makes code acceptable when it shouldn't! — widgg, May 24 '12 at 14:22
http://stackoverflow.com/questions/3473406/gcc-says-syntax-error-before-numeric-constant-in-generated-header-file-from-bi — memical, May 24 '12 at 14:26
thanks everyone... that part of the problem is solved! There's more, but at least, this one is done. Next project should be developed on Linux before or at least at the same time than the one on Windows! — widgg, May 24 '12 at 14:52

score 7 · Accepted Answer · answered May 24 '12 at 14:27

The fragment compiles fine with g++ 4.4.3, and I expect it also compiles fine with g++ 4.1.2.

What you've encountered is the reason using #define for constants is a fundamentally evil thing to do in C++. One of the header files you've included incorporates a line like:

#define V1 42

The fastest solution is

#undef V1

although, if someone has been malicious enough to #define V1 then I sense similar defines for V2 and V3 in your future. In my personal experience windows.h and many of the X11 headers are widely responsible for introducing preprocessor definitions like these.

I'd like to offer advice on tracking the offending header down, but I usually resort to grep and/or seeing which headers make the error go away when removed.

When we encounter this problem our general practice is to

Minimise the number of places the offending header is included - and never include it in a header file.
Create a "safe" wrapper header that #undefs all the offending constants and replaces them with something more reasonable if necessary.

it solves this problem... there's more left, but it's almost done! — widgg, May 24 '12 at 14:51

another g++ compilation error without any sense

1 Answers1