[test] Boost.Test fails to build with gcc-4.6
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<Lhs, Rhs,OP>::evaluate(bool) const [with LExpr = boost::test_tools::assertion::value_expr<int>, Rhs = int&, OP = boost::test_tools::assertion::op::EQ<int, int, void> ]' 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<int, int, void> >' ======== note that "Rhs = int&" for the first expression, while "int" in "binary_expr<..., int>" for the second expression. The corresponding code is ======== template<typename LExpr, typename Rhs, typename OP> class binary_expr : public expression_base<binary_expr<LExpr,Rhs,OP>,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<ValType,typename RhsT<T>::type> > operator ==( T&& rhs ) { return binary_expr<ExprType, T, op::name<ValType,typename RhsT<T>::type> > ( /* ... */ ) } 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? Raffi
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<Lhs, Rhs,OP>::evaluate(bool) const
[with LExpr = boost::test_tools::assertion::value_expr<int>, Rhs = int&, OP = boost::test_tools::assertion::op::EQ<int, int, void> ]'
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<int, int, void> >'
========
note that "Rhs = int&" for the first expression, while "int" in "binary_expr<..., int>" for the second expression.
The corresponding code is
======== template<typename LExpr, typename Rhs, typename OP> class binary_expr : public expression_base<binary_expr<LExpr,Rhs,OP>,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<ValType,typename RhsT<T>::type> > operator ==( T&& rhs ) { return binary_expr<ExprType, T, op::name<ValType,typename RhsT<T>::type> > ( /* ... */ ) }
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.
participants (3)
-
Andrey Semashev
-
John Maddock
-
Raffi Enficiaud