Boost logo

Boost :

Subject: Re: [boost] Conflicts when building libraries at root
From: Damien Buhl (damien.buhl_at_[hidden])
Date: 2015-03-10 06:23:09

On 10/03/2015 09:08, Andrey Semashev wrote:
> On Tuesday 10 March 2015 06:54:30 Damien Buhl wrote:
>> On 09/03/2015 23:20, Edward Diener wrote:
>>> On 3/9/2015 5:09 PM, Andrey Semashev wrote:
>>> [...]
>>>> There weren't any warnings before. Is this a result of a change in
>>>> Boost.PP?
>>> Yes, but they were already in 1.57. The changes added some new
>>> (BOOST_PP_IS_BEGIN_PARENS) and better functionality (the internal
>>> BOOST_PP_IS_EMPTY) to Boost PP, as well as fixing some corner cases with
>>> VC++ I discovered when testing VMD.
>> The reason why this happens more in this build, is that the new
>> BOOST_FUSION_ADAPT macros uses BOOST_PP_IS_EMPTY for each field member
>> now. This is used to determine if the type was provided or has to be
>> deduced.
> Is it possible to avoid BOOST_PP_IS_EMPTY? For example, use a keyword instead
> of testing for an empty string?

I'll change this to look at the implication that it has. Not sure it
will be better on old compilers like MSVC 8, but perhaps we can avoid
some warnings. :p

What is good is that the current code allow this change easily. Because
when BOOST_PP_VARIADICS support is active, it wouldn't be needed at all,
and when it's not there then it currently only uses BOOST_PP_IS_EMPTY to
check if the provided type is a macro which expands to BOOST_PP_EMPTY,

So it might be quite easy to replace it to make a check if the provided
type is a string equal to BOOST_FUSION_ADAPT_AUTO. Actually it makes
even more sense than the check for emptiness.

The only disadvandtage is that the user cannot anymore write nothing
instead of the type when he don't have BOOST_PP_VARIADICS support (which
is anyway undocumented and not advised).

Otherwise isn't there any possibility to fix the warnings in
BOOST_PP_IS_EMPTY? Because the old version of BOOST_PP_IS_EMPTY didn't
warn about anything AFAIK when used with a parameter which expands to

>>> Turning off C4003 globally for VC++ is the only solution to the VC++
>>> warnings I could ever discover. I attempted to turn off the warnings in
>>> the macros where they occur, but VC++ just ignores that. Evidently the
>>> warnings can only be turned off globally or possibly at the very
>>> top-level macro which eventually causes them.
>> Do you think I could add specific pragmas to disable C4003 where I use
> I suspect pragmas should envelop the place where the macro unfolds. In this
> case it's Boost.Phoenix. But in general this is user's code. And __pragma is
> not available in MSVC 8.

ok thanks for the info.

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