On Fri, Jan 20, 2012 at 2:41 PM, Cary Coutant <ccout...@google.com> wrote: >> 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.
If there were a defined way to test for extensions from within C (or C++), then this problem would be much reduced. Clang has something of a framework to query support for different features, and I drafted a proposal for something similar that would work across different compilers (with the intension of tracking C++11 features as they roll out), but that proposal went nowhere (I was too late for it to be useful for C++11 in any case). -- James
