Re: [boost] [Phoenix] lambda_tests.test fails on gcc 4.3-4.8 with BOOST_RESULT_OF_USE_DECLTYPE

Subject: Re: [boost] [Phoenix] lambda_tests.test fails on gcc 4.3-4.8 with BOOST_RESULT_OF_USE_DECLTYPE
From: Michel Morin (mimomorin_at_[hidden])
Date: 2012-10-07 03:04:58

Eric Niebler :
>> I ran Phoenix test-suite on * clang 3.1, 3.2 (trunk) * gcc 4.4-4.7,
>> 4.8 (experimental) with * C++03, C++11 +
>> BOOST_RESULT_OF_USE_DECLTYPE, C++11 + BOOST_RESULT_OF_USE_TR1
>>
>> The only failure is lambda_tests.test (i.e.
>> scope/lambda_tests.cpp) on gcc 4.4-4.7 with C++11 +
>> BOOST_RESULT_OF_USE_DECLTYPE. Is this caused by deficiency of N3276
>> decltype support?
>
> I don't know. Maybe Thomas can have a look. I tried to understand the
> code for Phoenix lambda and broke my brain. :-P This test also fails
> on msvc when BOOST_RESULT_OF_USE_DECLTYPE is defined.

I did additional tests: on clang 2.8-3.0 in a C++11 mode with
BOOST_RESULT_OF_USE_DECLTYPE, lambda_tests.test also failed.

During the tests, I found that runtime errors (BOOST_TEST failures) happen
in some tests (e.g. scope/let_tests.cpp) when compiling them with
optimization flag (-O2 or -O3) on both gcc (except gcc 4.5) and clang.
The runtime failures happen both in C++03 and C++11 modes.
I don't know if this is related to Boost.Proto, but I report this here
just in case.

>> P.S. What was the main reason for the incompatibility between
>> Phoenix and decltype-based result_of? And how did you fix it?
>
> A host of small problems, most of them pretty simple. Here's an example:
>
> struct Fun
> {
>   typedef void result_type;
>
>   template<typename T>
>   void operator()(T & t) const
>   {}
> };
>
> struct S {};
> typedef boost::result_of<Fun(S)>::type should_be_void_t;
>
> The trouble with this is that result_of will create an rvalue of type
> S and try to pass that to Fun's operator(). It will fail because
> rvalues don't bind to non-const lvalues. But this works fine with TR1
> result_of.
>
> For Phoenix, the fix was usually to make the function parameter a
> const ref. In other cases, the right fix might be to change the
> result_of invocation to: boost::result_of<Fun(S &)>.

I see. Thanks for sharing the information!

Regards,
Michel