Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
GCC attributes
Der Meister:
From revision 1502 on a file named 'src/sdk/gcc-attribs.h' entered the project. At first this seems to be no problem but in revision 1507 there were massive changes to this file. One of the changes was adding the makro __const__. This breaks (at least vor me) the codestats plugin (and possible more - it could even break the whole project. Seems as this didn't happen yet, I fear it could do it when nobody would expect it.). The problem is: The file '/usr/include/bits/mathcalls.h' contains lines like the following:
--- Code: ---__MATHCALLX (ceil,, (_Mdouble_ __x), (__const__));
--- End code ---
Now guess what happens :?
GCC throws lots of weired error messages. Error messages that seem to have no sense at all.
That is the best example why praeprocessor macros are evil. It took me two hours to find the reason for that problem.
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. 8)
rickg22:
Let's see what WebSVN says...
--- Quote ---Rev: 1507
Path: /trunk/src/sdk/gcc-attribs.h
Author: thomasdenk
Age: 2 days
Log message:
Changed gcc attribute macros to lowercase for better readability.
Changed likely() and unlikely() so they work with arbitrary values.
Added some more attribute macros.
Added attributes to the block allocator and to code completion.
Marked Manager::isappShutingDown() as deprecated.
--- End quote ---
Edit: I mailed him, I'm sure it'll be fixed in the next revision.
takeshimiya:
--- Quote from: rickg22 on December 16, 2005, 10:38:52 pm ---Don't we love SVN? :)
--- End quote ---
Yes.
And TortoiseSVN have a function just for this.
Just go to /src/sdk, and right-click on gcc-attribs.h ->TortoiseSVN->Blame.
And then, it will tell you the person to blame. :D
thomas:
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.
--- Quote from: Der Meister on December 16, 2005, 09:31:01 pm ---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. 8)
--- End quote ---
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.
Urxae:
[The risk of taking a long time to post: you get beaten to it :?]
--- Quote from: Der Meister on December 16, 2005, 09:31:01 pm ---From revision 1502 on a file named 'src/sdk/gcc-attribs.h' entered the project. At first this seems to be no problem but in revision 1507 there were massive changes to this file. One of the changes was adding the makro __const__. This breaks (at least vor me) the codestats plugin (and possible more - it could even break the whole project. Seems as this didn't happen yet, I fear it could do it when nobody would expect it.). The problem is: The file '/usr/include/bits/mathcalls.h' contains lines like the following:
--- Code: ---__MATHCALLX (ceil,, (_Mdouble_ __x), (__const__));
--- End code ---
Now guess what happens :?
GCC throws lots of weired error messages. Error messages that seem to have no sense at all.
That is the best example why praeprocessor macros are evil. It took me two hours to find the reason for that problem.
--- End quote ---
Well kids, remember this: don't use names that are reserved for the (C++) implementation, such as those containing a double-underscore, except as defined in the documentation of that same implementation :P.
--- Quote ---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. 8)
--- End quote ---
First thing, notice that the entire contents of the file (except include guards) are contained in an #if __GNUC__ >= 3 / #else / #end block, so the use of the macros defined in it shouldn't cause any problems on compilers other than gcc. (at least not on ones that don't define __GNUC__, which would be rather improper to do if you're not 100% source-compatible with gcc)
The reason to use such attributes is generally that they provide the compiler with extra information about your program that it can use to optimize it better. Since they are compiler specific extensions however, syntax and availability differs between compilers and thus packaging such attributes in macros is the usual solution. MSVC has extensions for at least some of those used in the file using the __declspec syntax, for example.
The reason to expand to nothing if not compiled on gcc instead of using those attributes is likely that C::B currently (AFAIK) doesn't compile on any other compilers anyway. If it did, they could be defined to something else in an #elif clause for other compilers.
Navigation
[0] Message Index
[#] Next page
Go to full version