Re: [Boost-users] Looping through variadic macro arguments

Subject: Re: [Boost-users] Looping through variadic macro arguments
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-03-31 06:27:04

On 3/31/2016 4:00 AM, Florian Lindner wrote:
>
>
> On Wed, 30 Mar 2016 14:42:41 -0400
> Edward Diener <eldiener_at_[hidden]> wrote:
>
>> On 3/30/2016 4:35 AM, Florian Lindner wrote:
>>> Hey,
>>>
>>> I have integrated the code in our project now and it fails to
>>> compile with some older clang version.
>>>
>>> It compiles fine with clang++ 3.7.1 and g++ 5.3.0 on my arch
>>> machine as well as g++ 4.8.4 on our ubuntu server, but fails with
>>> clang++ 3.4 on this machine as well as the travis
>>>
>>> The complete compiler messages are at http://pastebin.com/HgjgCfsH
>>> it is mostly something like that:
>>>
>>> error: unknown type name 'BOOST_PP_IIF_0'
>>>     assertion( reinterpret_cast<Vector&>(*this).size()==toAssign.size()
>>> );
>>>
>>> The assertions code is at
>>> https://github.com/precice/precice/blob/develop/src/utils/assertion.hpp
>>>
>>> as well as all other code files.
>>>
>>> If you want to give it a try, you can clone the project and use
>>>
>>> clang++ -o
>>> build/debug-nopetsc-nompi/tarch/configuration/ConfigurationRegistry.o
>>> -c -Wall -std=c++11 -fPIC -Wsign-compare -g3 -O0 -DDebug -DAsserts
>>> -DPRECICE_NO_PETSC -DEIGEN_INITIALIZE_MATRICES_BY_NAN
>>> -DPRECICE_NO_MPI -DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -Isrc
>>> -I/usr/include -I/usr/include/python2.7
>>> -I/usr/include/python2.7/numpy
>>> src/tarch/configuration/ConfigurationRegistry.cpp
>>>
>>> (it's also included in the pastebin above)
>>>
>>> Do you have any idea?
>>
>> Would you please post a complete example along with your command line
>> as a Boost bug report for the preprocessor library ? That way I am
>> more likely to take a look at it. My guess, without knowing the
>> details of your example, is just a clang-3.4 bug which has been fixed
>> in a later release but if your problem is easily reproducable I can
>> add a test to the preprocessor tests, based on your example, which
>> shows the clang-3.4 bug. Currently my preprocessor tests using
>> clang-3.4 do not show any problems so incorporating such a test
>> showing a problem will be worthwhile for me.
>
> Hey,
>
> I'm very happy to help that way.
>
> I was able to reproduce that bug in a small piece of code and was doing
> some tests using different versions.
>
> The bug is triggered using all clang versions (3.4 and 3.7.1 at least)
> if using boost 1.55, and obviously was fixed in 1.56.
>
> Do you still want me to open a bug report?

If the bug no longer exists in the latest Boost release then there is no 
longer a reason to open a bug report. But if you can reproduce the bug 
using the latest Boost release a bug report would be very helpful.

I realize many end-users do not use the latest Boost release but it is 
very difficult solving problems for end-users when a bug they have 
encountered has been subsequently fixed in a later Boost release than 
they are using.