Boost logo

Boost :

Subject: Re: [boost] [preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-01-18 08:30:57

On Sat, 14 Jan 2012 06:07:13 -0800, lcaminiti wrote:

>> 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.
> Yes, in scope_exit.hpp, I could do:
> #include <config.hpp>
> #endif
> #include <boost/preprocessor/variadic/size.hpp> ...

But that won't actually work in the real world as it depends on the order
of inclusion.

> But that way ScopeExit will make BOOST_PP_VARIADICS equivalent to
> BOOST_NO_VARIADIC_MACROS... that seems bad practice... then why having
> two macros in the first place?

As I said before, BOOST_PP_VARIADICS is a stronger requirement on the
preprocessor than !BOOST_NO_VARIADIC_MACROS. The reason is that it isn't
simply a flag that determines whether the preprocessor supports variadic
macros (superficially or otherwise). Instead, it enables a set of
functionality in the pp-lib that is highly dependent on the details of the
behavior of the preprocessor itself. This would be a non-issue if
preprocessors all actually conformed to respective standards, but they
don't. Because of that, the implementation is highly tuned for each
preprocessor known to work.

> The story is different if the forced definition of BOOST_PP_VARIADICS is
> left to the end user- the user is hen on his own in overriding the
> default detection of the Boost.Preprocessor configuration. However, that
> adds extra configuration effort on the user side so Boost.Preprocessor
> should be as accurate as possible in defining BOOST_PP_VARIADICS on all
> compilers that actually support Boost.Preprocessor variadics.

Variadic macros are a >= C99 and >= C++11 feature. They are not part of
the C++98 language, and thus they are not enabled by default on GCC when
GCC is not compiling those languages. Variadic macros enabled in C++98
are a compiler extension. If you want to force it, you can, but the pp-
lib is not going to use compiler extensions by default.

>>> 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.

It isn't that simple, though some preprocessors are worse than others. It
isn't an exact feature set so much as it is attempting to understand the
behavior of complex macro expansion algorithms used in any given
preprocessor with only the results of the algorithms rather than the
algorithms themselves. What works in one particular use case suddenly
fails in another for no apparent reason.

The problem is that our understanding of the behavior of the particular
preprocessor is only approximate, and that approximation deviates in a
combinatorial fashion (i.e. when you use interface A everything works,
when you use interface B everything works, but when you use both A and B
it fails).

This type of behavior is particularly apparent with VC++ as Edward can
attest to, and both Edward and I spent a significant amount of time
stabilizing the library on VC++ because it is such a popular compiler.

That said, Boost is used on a lot of different compilers. The pp-lib
specifically is used heavily throughout Boost either directly or
indirectly. The majority of Boost users don't use the pp-lib directly
just as they often don't use the MPL directly. Because of that, it is
more important that the libraries most commonly used in Boost are stable,
and that is why the pp-lib has to be what you probably consider to be
overly conservative.
>> Look at preprocessor/config/config.h for the internal logic for
> Yes, I found that logic (see below). But I was asking for exactly why
> this logic needs to be more conservative than BOOST_NO_VARIADIC_MACROS?
> In other words, what are the actual pp features that are required to
> GCC 4.5.x without -std=c++0x is a good example. Why is
> BOOST_PP_VARIADICS not automatically defined for this compiler? What are
> the specific issuers? I was able to use at least VARIADIC_SIZE and
> VARIADIC_TO_SEQ on that compiler without any issue at all...

Because C++98 doesn't have variadic macros. You want variadic macros, use
a C++0x/C++11 compiler or use the backdoor already provided (the command
line definition of BOOST_PP_VARIADICS).

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at