[Boost-users] Looping through variadic macro arguments

[Florian Lindner]

Hello,

I have this macro:

#define vmacro(expr, ...) \
cout << "n macro = " << BOOST_PP_VARIADIC_SIZE(__VA_ARGS__) << endl; \
cout << BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__) << endl; \
cout << BOOST_PP_VARIADIC_ELEM(1, __VA_ARGS__) << endl; \
for (int i = 0; i < BOOST_PP_VARIADIC_SIZE(__VA_ARGS__); i++) { \
cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \
}

The VARIADIC_SIZE is correct and I can access elements using BOOST_PP_VARIADIC_ELEM as long as I use a literal. The loop body produces error messages when compiling.
BOOST_PP_VARIADICS is 1.

The goal is to concatenate all variadic macro arguments to a string. If
there a more clever solution, I'm very eager to hear them.

Thanks!
Florian


ERROR MESSAGES:

% clang++ -std=c++11 -g3 -rdynamic -ldl test.cpp
test.cpp:154:3: error: expected expression
vmacro(4, 5, 6);
^
test.cpp:120:26: note: expanded from macro 'vmacro'
cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \
^
/usr/include/boost/preprocessor/variadic/elem.hpp:26:101: note: expanded from macro 'BOOST_PP_VARIADIC_ELEM'
# define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,)
^
1 error generated.


g++ -std=c++11 -g3 -rdynamic -ldl test.cpp
In file included from test.cpp:9:0:
test.cpp: In function 'void f(int)':
test.cpp:120:26: error: expected primary-expression before ')' token
cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \
^
test.cpp:154:3: note: in expansion of macro 'vmacro'
vmacro(4, 5, 6);
^
test.cpp:120:26: error: 'BOOST_PP_VARIADIC_ELEM_i' was not declared in this scope
cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \
^
test.cpp:154:3: note: in expansion of macro 'vmacro'
vmacro(4, 5, 6);
^


_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Edward Diener]

On 3/18/2016 6:19 AM, Florian Lindner wrote:
> Hello,
>
> I have this macro:
>
> #define vmacro(expr, ...) \
> cout << "n macro = " << BOOST_PP_VARIADIC_SIZE(__VA_ARGS__) << endl; \
> cout << BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__) << endl; \
> cout << BOOST_PP_VARIADIC_ELEM(1, __VA_ARGS__) << endl; \
> for (int i = 0; i < BOOST_PP_VARIADIC_SIZE(__VA_ARGS__); i++) { \
> cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \
> }
>
> The VARIADIC_SIZE is correct and I can access elements using BOOST_PP_VARIADIC_ELEM as long as I use a literal. The loop body produces error messages when compiling.
> BOOST_PP_VARIADICS is 1.

Your macro 'vmacro' gets expanded at preprocessor time when it is
invoked as 'vmacro(4,5,6)'. At preprocessor time the expansion of
'BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__)' fails because 'i' is not a
valid Boost PP number.

>
> The goal is to concatenate all variadic macro arguments to a string. If
> there a more clever solution, I'm very eager to hear them.

#include <boost/preprocessor/stringize.hpp>
#include <boost/preprocessor/seq/cat.hpp>
#include <boost/preprocessor/variadic/to_seq.hpp>

cout <<
BOOST_PP_STRINGIZE(BOOST_PP_SEQ_CAT(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)))
<< endl;

[Florian Lindner]

Hey,

On Fri, 18 Mar 2016 09:06:26 -0400
Edward Diener <eldi...@tropicsoft.com> wrote:

> On 3/18/2016 6:19 AM, Florian Lindner wrote:
> > Hello,
> >
> > I have this macro:
> >
> > #define
> > vmacro(expr, ...) \
> > cout << "n macro = " << BOOST_PP_VARIADIC_SIZE(__VA_ARGS__) <<
> > endl; \ cout << BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__) <<
> > endl; \ cout << BOOST_PP_VARIADIC_ELEM(1,
> > __VA_ARGS__) << endl; \ for (int i = 0; i <
> > BOOST_PP_VARIADIC_SIZE(__VA_ARGS__); i++) { \ cout << i << ":
> > " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \ }
> >
> > The VARIADIC_SIZE is correct and I can access elements using
> > BOOST_PP_VARIADIC_ELEM as long as I use a literal. The loop body
> > produces error messages when compiling. BOOST_PP_VARIADICS is 1.
>
> Your macro 'vmacro' gets expanded at preprocessor time when it is
> invoked as 'vmacro(4,5,6)'. At preprocessor time the expansion of
> 'BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__)' fails because 'i' is not a
> valid Boost PP number.

Thanks for your explanation!

> > The goal is to concatenate all variadic macro arguments to a
> > string. If there a more clever solution, I'm very eager to hear
> > them.
>
> #include <boost/preprocessor/stringize.hpp>
> #include <boost/preprocessor/seq/cat.hpp>
> #include <boost/preprocessor/variadic/to_seq.hpp>
>
> cout <<
> BOOST_PP_STRINGIZE(BOOST_PP_SEQ_CAT(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)))
> << endl;

I also want to write some text between the sequence items, I have made
it working with that code:

#define PRINT(r, data, elem) \
cout << "Argument " << r-1 << ": " << elem << endl;

#define vmacro(expr, ...) \
cout << "Expression: " << #expr << endl; \
BOOST_PP_SEQ_FOR_EACH(PRINT, ,
BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \

So, invoking vmacro(1-2, 5, 6, "Hallo"); prints

#define PRINT(r, data, elem) \
cout << "Argument " << r-1 << ": " << elem << endl;

#define vmacro(expr, ...)
\ cout << "Expression: " << #expr << endl; \
BOOST_PP_SEQ_FOR_EACH(PRINT, ,
BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \


Expression: 1-2
Argument 1: 5
Argument 2: 6
Argument 3: Hallo


Any comments on that? How to do it better? Maybe without a helper macro
PRINT?
I'm a bit surprised I have to use r-1 to get 1 for the first argument.

Best,
Florian

[Edward Diener]

On 3/21/2016 4:55 AM, Florian Lindner wrote:
> Hey,
>
snipped ...

>
> I also want to write some text between the sequence items, I have made
> it working with that code:
>
> #define PRINT(r, data, elem) \
> cout << "Argument " << r-1 << ": " << elem << endl;
>
> #define vmacro(expr, ...) \
> cout << "Expression: " << #expr << endl; \
> BOOST_PP_SEQ_FOR_EACH(PRINT, ,
> BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
>
> So, invoking vmacro(1-2, 5, 6, "Hallo"); prints
>
> #define PRINT(r, data, elem) \
> cout << "Argument " << r-1 << ": " << elem << endl;
>
> #define vmacro(expr, ...)
> \ cout << "Expression: " << #expr << endl; \
> BOOST_PP_SEQ_FOR_EACH(PRINT, ,
> BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
>
>
> Expression: 1-2
> Argument 1: 5
> Argument 2: 6
> Argument 3: Hallo
>
>
> Any comments on that? How to do it better? Maybe without a helper macro
> PRINT?
> I'm a bit surprised I have to use r-1 to get 1 for the first argument.

The PRINT macro is fine. Almost all Boost PP looping constructs use a
helper macro like that.

In real life code I would name all macros in uppercase and give them a
very distinct name to reduce clashes with other potential C++
identifiers and macros.

Look at BOOST_PP_SEQ_FOR_EACH_I to get the actual argument index instead
of using 'r'.

That 'r' in your code above is actually 2,3, and 4 is just luck. The
'next available BOOST_PP_FOR repetition' as described in the doc just
happened to be 2,3, and 4 but could theoretically have been any PP
number each time and is not related to the index of each argument.

[Florian Lindner]

On Mon, 21 Mar 2016 10:39:52 -0400
Edward Diener <eldi...@tropicsoft.com> wrote:

> On 3/21/2016 4:55 AM, Florian Lindner wrote:
> > Hey,
> >
> snipped ...
> >

[...]

> >
> >
> > Any comments on that? How to do it better? Maybe without a helper
> > macro PRINT?
> > I'm a bit surprised I have to use r-1 to get 1 for the first
> > argument.
>
> The PRINT macro is fine. Almost all Boost PP looping constructs use a
> helper macro like that.
>
> In real life code I would name all macros in uppercase and give them
> a very distinct name to reduce clashes with other potential C++
> identifiers and macros.

Sure!

> Look at BOOST_PP_SEQ_FOR_EACH_I to get the actual argument index
> instead of using 'r'.
>
> That 'r' in your code above is actually 2,3, and 4 is just luck. The
> 'next available BOOST_PP_FOR repetition' as described in the doc just
> happened to be 2,3, and 4 but could theoretically have been any PP
> number each time and is not related to the index of each argument.

Ok, try to use FOR_EACH_I, but ran into compilation errors:

#define PRINT(r, data, i, elem) \
cout << "Argument " << i << ": " << elem << endl;

#define vmacro(expr, ...) \
cout << "Expression: " << #expr << endl; \

BOOST_PP_SEQ_FOR_EACH_I(PRINT, , BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \


but:

% g++ -std=c++11 -g3 -rdynamic -ldl test.cpp && ./a.out :(

test.cpp: In function 'void f(int)':

test.cpp:127:27: error: 'PRINT' was not declared in this scope
BOOST_PP_SEQ_FOR_EACH_I(PRINT, , BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
^
test.cpp:159:3: note: in expansion of macro 'vmacro'
vmacro(1-2, 5, 6);
^
test.cpp:127:34: error: expected primary-expression before ',' token
BOOST_PP_SEQ_FOR_EACH_I(PRINT, , BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
^
test.cpp:159:3: note: in expansion of macro 'vmacro'
vmacro(1-2, 5, 6);
^
In file included from /usr/include/boost/preprocessor/variadic/to_seq.hpp:17:0,
from test.cpp:11:
test.cpp:127:36: error: expression cannot be used as a function
BOOST_PP_SEQ_FOR_EACH_I(PRINT, , BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
^
test.cpp:159:3: note: in expansion of macro 'vmacro'
vmacro(1-2, 5, 6);
^
test.cpp:127:73: error: 'BOOST_PP_SEQ_FOR_EACH_I' was not declared in this scope
BOOST_PP_SEQ_FOR_EACH_I(PRINT, , BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
^
test.cpp:159:3: note: in expansion of macro 'vmacro'
vmacro(1-2, 5, 6);
^


boost 1.60, gcc 5.3.0.

The same code, using FOR_EACH works (only the argumentens of PRINT were altered.

Thanks!

Florian

[Edward Diener]

What is that final '\' about ?

Please show the header files being included.

[Florian Lindner]

On Tue, 22 Mar 2016 20:53:06 -0400

That is obviously unneeded, but not the cause.

> Please show the header files being included.

Sorry, my fault. I included the Header for for_each not for for_each_i.

Best,
Florian

[Florian Lindner]

Hello,

another question: I was expecting that the line

BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__));

in a macro #define vm(expr, ...) expands to nothing, when the the macro is called with just one argument vm(false), but it fails, only when called with just one argument:

% g++ -std=c++11 -g3 test.cpp

test.cpp: In function 'void f(int)':

test.cpp:109:51: error: expected primary-expression before '<<' token
std::cerr << " Argument " << i << ": " << elem << std::endl;
^
/usr/include/boost/preprocessor/seq/for_each_i.hpp:85:66: note: in expansion of macro 'PRINT_ARGUMENT'
# define BOOST_PP_SEQ_FOR_EACH_I_M_I(r, macro, data, seq, i, sz) macro(r, data, i, BOOST_PP_SEQ_HEAD(seq))
^
test.cpp:140:1: note: in expansion of macro 'assertion'
assertion(!true);
^


Is there any way to make it work like that?

Thanks a lot!
Florian

The code looks like that:

#define PRINT_ARGUMENT(r, data, i, elem) \
std::cerr << " Argument " << i << ": " << elem << std::endl;

#define assertion(expr, ...) if (!(expr)) { \
std::cerr << "Assertion in " << __FILE__ << ":" << __LINE__ \
<< ", failed expression: " << #expr << std::endl; \
std::cout << BOOST_PP_VARIADIC_SIZE(__VA_ARGS__) << std::endl; \
BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__)); \
std::cerr.flush(); \
std::cout.flush(); \
assert(false); \
} \



On Tue, 22 Mar 2016 20:53:06 -0400

[Edward Diener]

On 3/23/2016 11:45 AM, Florian Lindner wrote:
> Hello,
>
> another question: I was expecting that the line
>
> BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,, BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__));
>
> in a macro #define vm(expr, ...) expands to nothing, when the the macro is called with just one argument vm(false), but it fails, only when called with just one argument:
>
> % g++ -std=c++11 -g3 test.cpp
>
> test.cpp: In function 'void f(int)':
> test.cpp:109:51: error: expected primary-expression before '<<' token
> std::cerr << " Argument " << i << ": " << elem << std::endl;
> ^
> /usr/include/boost/preprocessor/seq/for_each_i.hpp:85:66: note: in expansion of macro 'PRINT_ARGUMENT'
> # define BOOST_PP_SEQ_FOR_EACH_I_M_I(r, macro, data, seq, i, sz) macro(r, data, i, BOOST_PP_SEQ_HEAD(seq))
> ^
> test.cpp:140:1: note: in expansion of macro 'assertion'
> assertion(!true);
> ^
>
>
> Is there any way to make it work like that?

When you specify '...' to indicate variadic arguments you must always
supply at least one argument. That's part of the C++ standard.

The way to make 'vm' work is to specify:

#define vm(...)

and then extract your first argument and pass the remaining arguments,
if they exist, to your BOOST_PP_SEQ_FOR_EACH_I expansion. I will let you
figure out how to do that, but if you find you can't figure it out post
back and I will show you the code.

[Florian Lindner]

Hey,

ok, I used SEQ_TAIL for that and it works nicely:

#define PRINT_ARGUMENT(r, data, i, elem) \

std::cerr << " Argument " << i << ": " << elem << std::endl;

#define assertion(...) if (not BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) { \

std::cerr << "Assertion in " << __FILE__ << ":" << __LINE__ \

<< ", failed expression: " << BOOST_PP_STRINGIZE(BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) << std::endl; \
BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,, BOOST_PP_SEQ_TAIL(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))); \

std::cerr.flush(); \
std::cout.flush(); \
assert(false); \
}

as you can see, it's going to be an asssert macro. STRINGIZE gives me the literal expression, like the # operator.

Any comments?

Best Thanks,
Florian

[Edward Diener]

That's the solution.

I could add a BOOST_PP_VARIADIC_TAIL but keeping the Boost PP variadic
macros to a minimum was the idea when they were created.

>
> #define PRINT_ARGUMENT(r, data, i, elem) \
> std::cerr << " Argument " << i << ": " << elem << std::endl;
>
> #define assertion(...) if (not BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) { \

Wouldn't

if !(BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) { \

be better ?

> std::cerr << "Assertion in " << __FILE__ << ":" << __LINE__ \
> << ", failed expression: " << BOOST_PP_STRINGIZE(BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) << std::endl; \
> BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,, BOOST_PP_SEQ_TAIL(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))); \
> std::cerr.flush(); \
> std::cout.flush(); \
> assert(false); \
> }
>
> as you can see, it's going to be an asssert macro. STRINGIZE gives me the literal expression, like the # operator.
>
> Any comments?

I'm glad Boost PP is useful to you <g>. If you are further interested in
preprocessor programming in general you might find my Boost VMD library
interesting ( shameless plug ) <g>.

[Florian Lindner]

On Thu, 24 Mar 2016 11:00:57 -0400

The if condition needs to be enclosed by parens, don't it? This piece
of code does not compile?
Or do you propose to replace the "not" by "!"? I think they are the
same, I just like the "not" better, since it's more literal.

>
> > std::cerr << "Assertion in " << __FILE__ << ":" <<
> > __LINE__ \ << ", failed expression: " <<
> > BOOST_PP_STRINGIZE(BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) <<
> > std::endl; \ BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,,
> > BOOST_PP_SEQ_TAIL(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))); \
> > std::cerr.flush();
> > \
> > std::cout.flush();
> > \
> > assert(false);
> > \ }
> >
> > as you can see, it's going to be an asssert macro. STRINGIZE gives
> > me the literal expression, like the # operator.
> >
> > Any comments?
>
> I'm glad Boost PP is useful to you <g>. If you are further interested
> in preprocessor programming in general you might find my Boost VMD
> library interesting ( shameless plug ) <g>.

Thanks, I'll keep it in mind. But I try to keep preprocessor
programming to a minimum.

Best,
Florian

[Edward Diener]

Yes, of course. My error ( wipes egg off face ).

> Or do you propose to replace the "not" by "!"? I think they are the
> same, I just like the "not" better, since it's more literal.

OK. I rarely use the alphabetic alternatives to the logical operators.

>
>>
>>> std::cerr << "Assertion in " << __FILE__ << ":" <<
>>> __LINE__ \ << ", failed expression: " <<
>>> BOOST_PP_STRINGIZE(BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__)) <<
>>> std::endl; \ BOOST_PP_SEQ_FOR_EACH_I(PRINT_ARGUMENT,,
>>> BOOST_PP_SEQ_TAIL(BOOST_PP_VARIADIC_TO_SEQ(__VA_ARGS__))); \
>>> std::cerr.flush();
>>> \
>>> std::cout.flush();
>>> \
>>> assert(false);
>>> \ }
>>>
>>> as you can see, it's going to be an asssert macro. STRINGIZE gives
>>> me the literal expression, like the # operator.
>>>
>>> Any comments?
>>
>> I'm glad Boost PP is useful to you <g>. If you are further interested
>> in preprocessor programming in general you might find my Boost VMD
>> library interesting ( shameless plug ) <g>.
>
> Thanks, I'll keep it in mind. But I try to keep preprocessor
> programming to a minimum.

Sure.

There are some really neat things you can do using the preprocessor
using Boost PP, and Boost VMD extends that realm when variadic
parameters are available, as they are for all modern compilers.

Both libraries are aids for more complicated C++ macro writing than normal.

[Florian Lindner]

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?

Best,
Florian


On Tue, 29 Mar 2016 09:32:54 -0400

[Edward Diener]

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.

[Florian Lindner]

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?

Best,
Florian

[Edward Diener]

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.