Hm, my mistake. Nevertheless, you yourself said it?s not working in MinGW?s GCC 4.6, but I know static_assert is in C++ for GCC 4.6 (heck, the relevant page says it went in in version *4.3*). I guess there could be a difference with MinGW, but seems worth checking out if maybe it?s present in g++ but not gcc?
Occasionally I need to have some sort of "special" include file - and a different extension helps to make things clear. On a project I am working on at the moment, I want compile-time calculated hash values for some strings - but this cannot be achieved in C and the C pre-processor (it could be done with C++ templates). So I have a python script that is called as part of "make" that generates an include file with the hashes needed. This include file has a different extension, and lives in a different directory, to keep everything clear. (And it's usage doesn't break my rules above.)
There are typically many ways, depending on exactly what you are trying to achieve. In this case, I'd probably go for a normal "enum" in errorCodes.h, and an array in errorCodes.c with designated initialisers.
But if it is more more complicated, I would prefer to have a script (again, Python is my choice for such things - but any good scripting language would do) that generates errorCodes.h and errorCodes.c from the list of error codes. This gives you vastly more flexibility than you can get from the C pre-processor. (Consider, for example, if you want to include special characters such as " or non-English letters in the strings.)
Yes, the scope is limited - but it is still a style that I strongly dislike.
Sorry, I did not mean that you should be able to put the #include statements /anywhere/ - I meant in any order and any number of times in the place where #include statements should go, which is at the top of the C or H file. The point is, if you have headers such as "module1.h" and "module2.h" then it should never matter if you include "module1.h" before or after "module2.h", or that you include "module1.h" twice, or that you include "module2.h" even if you don't need it. And if "module2.h" depends on "module1.h" (such as for typedefs or defines), then "module2.h" should include "module1.h" itself.