Re: [boost] [preprocessor] [variadic] BOOST_PP_VARIADICS vs BOOST_NO_VARIADIC_MACROS

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:
>> 
>> #define BOOST_PP_VARIADICS
>> 
>> 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>
> #ifndef BOOST_NO_VARIADIC_MACROS
> #define BOOST_PP_NO_VARIADICS
> #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
>> defining BOOST_PP_VARIADICS.
>> 
>> 
> 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
> define BOOST_PP_VARIADICS but not to define BOOST_NO_VARIADIC_MACROS.
> 
> 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).

Regards,
Paul Mensonides