[predef] [rfc] Mutually exclusive definitions?
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. Currently Boost.Predef will define multiple symbols when, for example, a compiler "emulates" another compiler. The current common occurrence of this is the GCC compiler which many other compilers emulate by defining the GCC version macros. This is no longer the case for the OS definitions though. The OS definitions are mutually exclusive. And hence in order to make for a more consistent behavior I am considering changing the library to make not just OS defs mutually exclusive. But also making compiler, library, and architecture mutually exclusive. And I'm asking for some general feedback as to what the most useful approach, from using Boost.Predef, is likely to be. 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. 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. 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". 4. Do nothing and live with multiple definitions and the current discrepancy in behavior for BOOST_OS definitions. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On Jan 12, 2014, at 10:17 PM, Rene Rivera
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)
On 01/13/2014 04:17 AM, Rene Rivera wrote:
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.
I prefer this solution. No emulation is going to be perfect, and using these macros will make it clear when we are dealing with workarounds of the emulation in specific compilers.
participants (3)
-
Bjorn Reese -
Rene Rivera -
Rob Stewart