Well, apologies for your inconvenience. What can I say... the macro redefines a keyword, which is of course illegal (but which normally works nevertheless). I'll change the macros so they use single underscores instead of double underscores, this should fix your problem.
And yes, you are right, this is a good example why macros are evil.
Anyway, why is Code::Blocks even using gcc extensions? Using compiler specific things (especially compiler specific extensions) is a very bad practice (at least in my opinion). Is there any reason why Code::Blocks now uses them? It should be a very very good one - or I'll be rather disappointed.
This is easily explained. I introduced gcc extensions because they are there, and because you
can use them. It is bad practice to use them if you do not take provisions that you can still use other compilers, but these were taken. The macros evaluate to a gcc attribute definition when compiled with gcc, and to an empty string in all other cases. I do not see that as bad practice, I see it as making use of features which are useful. For example,
if(unlikely(ptr == 0)) gives valuable hints to the compiler - the branch for the null pointer is almost never taken, and gcc is able to optimize the code accordingly. On compilers other than gcc,
unlikely(x) evaluates to
(x), so you don't really give away anything.
Another good example is the function
IsAppShutingDown. This function is misspelled, but for backwards compatibility, it is still in the API. Now, thanks to attributes, that function is marked with the deprecated attribute. Not only can you see it in the header, but if you actually use that function,
gcc will tell you that it is deprecated and you should not be using it. I see that as an improvement.
The problem you encountered is not due to using attributes, but because I chose a bad macro name. Prior to 1507, the macros were in capitals, but PURE and DEPRECATED are so darn ugly, hence I changed them.
__const__ and
__inline__ were indeed bad choices, granted.