Dominique Devienne
On Wed, Jan 22, 2014 at 11:25 AM, Alexander Lamaison
wrote: [...] As for as I'm aware, the only change is to the assertion macros, which move to a more natural syntax:
BOOST_CHECK_EQUAL(a, b) becomes BOOST_TEST(a == b) BOOST_CHECK_LT(a, b) becomes BOOST_TEST(a < b) ... etc. BOOST_REQUIRE_EQUAL(a, b) becomes BOOST_TEST_REQUIRE(a == b) ... etc. BOOST_WARN_EQUAL(a, b) becomes BOOST_TEST_WARN(a == b)
But don't we then miss better messages which actually show the values themselves when the assert fails? I do BOOST_CHECK(a == b) only when a and b lack the op<<, but otherwise greatly prefer BOOST_CHECK_EQUAL(a, b).
Actually, no. BOOST_CHECK(a <operator> b) expands to something like: bool x = (a <operator> b) BOOST_CHECK_IMPL(x, "a <operator> b"); int x = 1; int y = 2; BOOST_CHECK(x == y)
"Assertion failed (file:line): !(x == y)"
so you lose the information about a and b, and which operator was used to test their relationship. BOOST_TEST(a <operator> b), however, cleverly parses a, b and <operator> from the macro and does something like bool x = (a <operator> b) BOOST_CHECK_MESSAGE_IMPL(x, "a must be <operator> to b", a, b); int x = 1; int y = 2; BOOST_TEST(x == y)
"Assertion failed (file:line): "x must be == to y: 1 != 2"
Obviously, the above is pseudocode nonsense, but you get the idea.
And what's the point of going from BOOST_REQUIRE(expr) to BOOST_TEST_REQUIRE(expr), i.e. make it longer / more typing?
The macros had to change anyway because the behaviour was changing. The Boost preferred-practice is to prefix new macros with BOOST_ and the name of the library, so all new Boost.Test macros should start BOOST_TEST*. As 'CHECK' is the assertion level you should use by default, BOOST_TEST with no suffix gets the 'CHECK' behaviour. The 'REQUIRE' and 'WARN' behaviours are chosen by adding the suffix, as before. Alex -- Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)