Boost logo

Boost :

Subject: Re: [boost] [predef] [rfc] Mutually exclusive definitions?
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2014-01-13 05:39:09


On Jan 12, 2014, at 10:17 PM, Rene Rivera <grafikrobot_at_[hidden]> wrote:

> After going back and re-reading various commentaries for the review of Boost.Predef and some after the review I'm questioning a design choice of
> Boost.Predef.

[snip]

> In particular I'm considering the following choices:
>
> 1. Simple mutual exclusion of BOOST_ARCH_*, BOOST_COMP_*, BOOST_LIB_C_*,
> BOOST_LIB_STD_*, and of course BOOST_OS_* definitions.

That's the most straightforward, but hides available information.

> 2. Mutual exclusion of the base/real definitions with the addition of *_EMULATED definitions when multiple defs detected. For example for GCC we would have BOOST_COMP_GCC_EMULATED indicated the version of the GCC being emulated.

That seems the best course. Typical usage is to identify the actual compiler. When emulation is supposed to be good enough for some case, the alternative constants give that. After all, most feature manifest constants will be specified carefully and may need to ignore an incomplete emulation. The clear distinction, in this version, makes that easier.

> 3. No mutual exclusion of base definitions but with the addition of a "flag" definition when multiple defs are detected. For example with GCC it would have the usual BOOST_COMP_GCC but also have a "#define
> BOOST_COMP_GCC_IS_EMULATED".

That would lead to more complicated expressions in simple case.

> 4. Do nothing and live with multiple definitions and the current discrepancy in behavior for BOOST_OS definitions.

Consistency is always a good starting point. In this case you're right to question the different handling
In the current design.

___
Rob

(Sent from my portable computation engine)


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