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

On 3/31/2016 4:00 AM, Florian Lindner wrote:

On Wed, 30 Mar 2016 14:42:41 -0400 Edward Diener 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(*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.