On 2/27/2012 2:55 AM, Mathias Gaunard wrote:
On 02/26/2012 03:25 PM, Bjorn Reese wrote:
On 2012-02-26 14:59, Mathias Gaunard wrote:
DragonEgg and llvm-gcc define both __GNUC__ and __llvm__. I don't see any problem there with telling that it's a GCC frontend with a LLVM backend.
Clang also defines those two macros even though it is not using GCC as a frontend.
But Clang defines __clang__, which the compilers above do not.
In other words.. We need to make a distinction between the *actual* compiler vs. the *compatible/emulated* compiler. There are obviously three options to this: 1. Make the default/base/undecorated definitions reflect the *actual* compiler. And add a set of predefs for the *emulated* compiler. 2. Make two different parallel sets of definitions, one for *actual* and one for *emulated*. 3. Make the default/base/undecorated definitions reflect the *emulated* compiler. And add a set for the *actual* compiler. Technically there isn't much difference between them. It's a question about is there a useful default interpretation of "what compiler you are using". I can think that option 2 is less likely to be useful than 1 and 3, and I would put option 3 slightly higher in preference because of the likelihood that if you are writing based on what features a compiler has, it's the compiler interface/API that you are interested in. And hence making your code more forward portable by using a default that reflects the *emulation*. Making the workarounds use cases the minority. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail