error: expected unqualified-id in prep.h [resolved]

[stardust]

Hi, when I try to rebuild a plugin I get the following errors. I cannot see what is wrong in prep.h. The plugin used to compile...

./src/include/prep.h:59: error: expected unqualified-id before numeric constant
./src/include/prep.h:63: error: expected unqualified-id before numeric constant

SVN 3695

[Biplab]

Add the following compiler options to your project.

Code

-Ulinux -Uunix

This would solve your problem.

Regards,

Biplab

[stardust]

Thanks, that fixed the problem.

I wonder why such variable names are used at all...

[Biplab]

Actually this has been due to few recent changes made to core. SDK manual has not been updated yet in Berlios. Once updated you'll come to know which part has been changed.

I wonder why such variable names are used at all...

Please read the following thread and you'll understand why it has been changed.

http://forums.codeblocks.org/index.php/topic,5396.msg41954.html#msg41954

Regards,

Biplab

[stardust]

Ok, I see.

So the approach should be to add

Code

-ansi

to the gcc options  -- which actually fixes the problem, too -- rather than saying

Code

-Uall-non-ansi-stuff

However, when I add "-ansi" to the project's build options, then C::B ignores that! I.e. when I reopen the build options->compiler->other, then the "-ansi" is gone!!

[Biplab]

Well, I'm not sure how it affects the other part of code. Officially -Ulinux -Uunix has been added as only those two were needed to be undef-ed.

[TDragon]

However, when I add "-ansi" to the project's build options, then C::B ignores that! I.e. when I reopen the build options->compiler->other, then the "-ansi" is gone!!

Check the Compiler Flags tab.
("In C mode, support all ISO C90 programs. In C++ mode, ...")

[thomas]

I wonder why such variable names are used at all...

The omnipresent macro abuse and #ifdef sections that are necessary to cope with the deficiencies and incompatibilities in wxWidgets make our code more and more unmaintainable and unreadable.
Last weekend, I gave up on some long due refactoring of a core class because I was honestly unable to figure out what a section of code spread between five (!) nested #ifdefs was doing. Also, we have several sections of code in our program that don't work because nobody (not even the person who wrote the code in the first place) understands what is going on.

The variable platform::linux is one of several new globally available constants that are evaluated at compile time, using as little preprocessor functionality as possible. It is an entirely legal name, and it is encapsulated in a namespace to avoid collisions. The only problem is that gcc defines a non-standard conforming macro with the same name and macros don't give a crap about namespaces.

So the approach should be to add

Code

-ansi

to the gcc options  -- which actually fixes the problem, too -- rather than saying

Code

-Uall-non-ansi-stuff

Nice idea, except that
a) it does not solve the problem because those two macros are still defined
b) the build will abort as soon as you include the first wxWidgets header file

The two known offending macros are linux and unix. Undefining them solves the issue for good. Yiannis added the fix to the makefile today. Maybe, possibly, there is a similar issue with MacOS, but so far nobody has complained yet (the solution to the problem will be the same).

I am sorry for the inconvenience caused by this update. However, those changes help making the code more readable and more maintainable in the future.
The goal is to write C++ code instead of preprocessor commands.