Re: [boost] [test] Boost.Test fails to build with gcc-4.6

On 2016-03-03 23:32, Raffi Enficiaud wrote:

Le 03/03/16 12:04, John Maddock a écrit :

...

See http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g...

The compiler looked broken to me (works eg. in 4.7), so I did not pay that much attention to that, but maybe I should reconsider.

An example of error says this:

======== test_case_template-test.cpp:38:5: error:

'boost::test_tools::assertion::binary_expr::evaluate(bool) const

[with LExpr = boost::test_tools::assertion::value_expr<int>, Rhs = int&, OP = boost::test_tools::assertion::op::EQ ]'

is not a member of

'boost::test_tools::assertion::binary_expr< boost::test_tools::assertion::value_expr<int>, int, boost::test_tools::assertion::op::EQ >'

========

note that "Rhs = int&" for the first expression, while "int" in "binary_expr<..., int>" for the second expression.

The corresponding code is

======== template class binary_expr : public expression_base,typename OP::result_type> { public: // snip

assertion_result evaluate( bool no_message = false ) const { // ....

========

This is an issue I was trying to fix for some time now. It appeared so far only for gcc in C++0X mode and not in C++11. This is the following:

Say I have this:

template<typename T> binary_expr< ExprType, T, op::name > operator ==( T&& rhs ) { return binary_expr > ( /* ... */ ) }

The compiler complains because the type in the declaration and inside the function mismatch, for some reason I do not get. Especially the type "T" is seen as eg. "int&" from outside the function (eg. from "auto"), while "T" is seen as "int" at the return statement.

Maybe this is a known issue in gcc and easy to fix?

Is there any progress? I'm seeing these failures: http://www.boost.org/development/tests/develop/developer/output/igaztanaga-g... From the look at the code I might suggest two solutions. First is easy, just add a check for gcc > 4.6 to boost/test/utils/runtime/errors.hpp:81. The second approach is to make the operator<<'s members of specific_param_error. This would also allow to remove the preprocessor check altogether.