Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

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

<< < (2/2)

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:

--- Quote from: stardust on March 14, 2007, 04:42:46 pm ---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!!

--- End quote ---
Check the Compiler Flags tab. :D
("In C mode, support all ISO C90 programs. In C++ mode, ...")

thomas:

--- Quote from: stardust on March 14, 2007, 03:26:51 pm ---I wonder why such variable names are used at all...
--- End quote ---
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. :(


--- Quote from: stardust on March 14, 2007, 04:42:46 pm ---So the approach should be to add

--- Code: ----ansi
--- End code ---
to the gcc options  -- which actually fixes the problem, too -- rather than saying

--- Code: ----Uall-non-ansi-stuff
--- End code ---

--- End quote ---
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.

Navigation

[0] Message Index

[*] Previous page