Hi, Cary Coutant <ccout...@google.com> skribis:
>> Yeah, but it’s a shame that those compilers define __GNUC__ without >> supporting 100% of the GNU C extensions. With this approach, you would >> also need to add !defined for Clang, PGI, and probably others. > > Having worked on the other side for a while -- for a vendor whose > compiler supported many but not all of GCC's extensions -- I claim > that the problem is with the many examples of code out there that > blindly test for __GNUC__ instead of testing for individual > extensions. From the other vendor's point of view, it's nearly useless > to support any of the GCC extensions if you don't also define > __GNUC__, because most code out there will simply test for that macro. > By defining the macro even if you don't support, for example, nested > functions, you can still compile 99% of the code that uses the > extensions. Thanks, I see. I think the problem is that __GNUC__ is (ab)used to refer to the GNU C language (any version), whereas it’s initially meant to refer to the compiler implementation. Maybe CPP assertions could be revived to test for single language features? Ludo’.
