Boost logo

Boost :

Subject: Re: [boost] [Predef] Pre-review comments
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2012-02-28 01:06:39


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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk