Re: [Boost-users] Problem with variadic BOOST_PP_TUPLE_REM in Clang

Subject: Re: [Boost-users] Problem with variadic BOOST_PP_TUPLE_REM in Clang
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-11-20 11:36:44

On 11/20/2013 8:39 AM, Paul Mensonides wrote:
> On Thu, 14 Nov 2013 18:59:39 -0500, Edward Diener wrote:
>
>> On 11/14/2013 5:40 PM, Matt Calabrese wrote:
>>> On Thu, Nov 14, 2013 at 5:26 AM, Edward Diener <eldiener_at_[hidden]
>>> <mailto:eldiener_at_[hidden]>> wrote:
>>>
>>>      Currently Boost PP does not depend on any other Boost library, not
>>>      even Config.
>>>
>>>      I imagine that Paul might respond to this issue. If he does not I
>>>      will notify him of it.
>>>
>>>
>>> Regardless, since both C99+ and C++11+ have variadic macros, it should
>>> probably be updated to a new BOOST_PP_NO_VARIADICS macro so that we
>>> assume compliance by default.
>>
>> I think that adding another macro confuses the issue even if it mimics
>> the style of config macros.
>>
>> It is not my call to change the code for determining what compiler
>> should automatically have variadic support enabled in Boost PP, even if
>> I worked prettily heavily on variadic macro support in general in Boost
>> PP with Paul. It's still his library to decide on this IMO and, even
>> though the change is fairly trivial in a single header file, I feel on
>> principal he has to agree to it. I will point this thread out to him.
>>
>> The end-user can always currently set BOOST_PP_VARIADICS to 1 for any
>> compiler to override the Boost PP automatic setting for that particular
>> compiler, but I do understand your feeling that nearly all compilers now
>> support variadic macros so it should be on, unless set off.
>
> The basic problem here is that BOOST_PP_VARIADICS is a lot stronger than
> just "compiler supports variadic macros in some form".  The pp-lib doesn't
> pull Boost.Config for two main reasons.  First, Boost.Config's variadic
> macros support macro is much weaker than what is required by a
> preprocessor metaprogramming library.  Second, unlike the rest of Boost,
> the pp-lib is used outside of just C++ contexts--in real code in the real
> world.  I.e. it is a C/C++ library, so it cannot pull in code assumed to
> target C++ only.  Even if this is not the case with current Boost.Config,
> the pp-lib cannot place this restriction on Boost.Config (and vice versa).
>
> I just checked and the showstopper bug in clang has apparently been
> fixed.  However, I have not personally confirmed this.  Can someone that
> has a current clang build confirm?
>
> http://llvm.org/bugs/show_bug.cgi?id=12767

The bug does not occur in the current clang build, so it is fixed in my 
test.

>
> Otherwise, if everything is working properly as far as we can tell, I have
> no issue with enabling by default on clang.

I can do this on 'trunk'. I have been working with clang in testing 
Boost PP, while also updating some of the Boost PP tests, and it is 
passing all tests.

>
> Regarding the pp-lib in general... it is legacy code that is fundamentally
> gimped by several preprocessors--notably msvc.  If all of the
> preprocessors were good, the entire library would be different--i.e. it
> would be more like chaos-pp.  Perhaps after this git modularization stuff,
> chaos-pp goes into Boost (though I personally think that git is an
> abomination and I'm not at all certain about what "Boost" will even mean
> at that time).

I encourage you to submit chaos-pp for inclusion into Boost. I see no 
reason why a library, without any compiler workarounds, cannot be part 
of Boost even if it does not work on all compilers because of some 
deficiency(s) in particular compilers.

>  It is also possible that MS makes good on their promise to
> fix their preprocessor, but I'll believe that when I see it (and then look
> for ulterior motives).

I have not tested VC++12, but nothing in the online description of its 
fixes suggest that the VC++ preprocessor has been fixed yet. If chaos-pp 
were part of Boost it would also be an excellent way to determine if the 
VC++ preprocessor has been fixed at some future point in time.

>
> Otherwise, for code outside of Boost, if you only have to target non-crap
> compilers, use chaos-pp.  It is a far superior library distributed under
> the same license.