Subject: Re: [boost] [preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS
From: Edward Diener (eldiener_at_[hidden])
Date: 2012-01-14 08:48:01
On 1/14/2012 5:42 AM, Lorenzo Caminiti wrote:
> On Sun, Dec 18, 2011 at 10:18 AM, Paul Mensonides<pmenso57_at_[hidden]> wrote:
>> On Sat, 17 Dec 2011 12:45:26 -0800, lcaminiti wrote:
>>> Why does Boost.Preprocessor redefines BOOST_PP_VARIAIDCS instead of just
>>> using BOOST_NO_VARIADIC_MACROS from Boost.Config?
>> The pp-lib requires more than just superficial variadic macro support.
>> I.e. BOOST_PP_VARIADICS macro is stronger.
>>> Furthermore, GCC supports variadics also when C++11 extensions are not
>>> enabled so I think the following should not&&
>>> // File: boost/preprocessor/config/config.hpp # /* Wave (C/C++), GCC
>>> (C++) */
>>> # elif defined __WAVE__&& __WAVE_HAS_VARIADICS__ || defined __GNUC__
>>> && __GXX_EXPERIMENTAL_CXX0X__
>>> # define BOOST_PP_VARIADICS 1
>> Because it isn't standard C++98. It can be enabled via a command line
>> definition of BOOST_PP_VARIADICS. It is enabled by default (on GCC) when
>> in C++11 mode. I believe that GCC 4.7 actually finally defines __cplusplus
>> correctly as well.
> It is annoying to manually -DBOOST_PP_VARIADICS. That is especially
> true for libraries like Boost.ScopeExit and Boost.Closure that use
> variadics in their public APIs so the end user is required to manually
> define BOOST_PP_VARIADICS when Boost.Preprocessor does not
> automatically detect it... (e.g., on GCC 4.5.3 without -std=c++0x).
You can just add:
in your header files before using Boost PP headers. That isn't really
that annoying to do if you want to force it.
> Can we define what "extra" features are required by BOOST_PP_VARIADICS
> so I can write tests and run them to the Boost compilers and then
> refine the definition of BOOST_PP_VARIADICS to automatically detect
> all compilers where Boost.Preprocessor variadic support work.
Look at preprocessor/config/config.h for the internal logic for defining
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk