2

We're using Boost::Test to unit test our code (Visual Studio 2010, win32 C++ project). Since we're often working with Ogre::Vector3 objects (geometrical vectors in 3D space) I've written this wrapper to easily test two Vector3 objects for almost-equality:

static const double EPSILON = 1e-7;

void CHECK_CLOSE(const Ogre::Vector3 & actual, const Ogre::Vector3 & expected, Ogre::Real tolerance) {
    if (std::fabs(expected.x) < EPSILON) BOOST_CHECK_SMALL(actual.x, tolerance);
    else  BOOST_CHECK_CLOSE(actual.x, expected.x, tolerance);

    if (std::fabs(expected.y) < EPSILON) BOOST_CHECK_SMALL(actual.y, tolerance);
    else  BOOST_CHECK_CLOSE(actual.y, expected.y, tolerance);

    if (std::fabs(expected.z) < EPSILON) BOOST_CHECK_SMALL(actual.z, tolerance);
    else  BOOST_CHECK_CLOSE(actual.z, expected.z, tolerance);
}

Unfortunately, when one of the BOOST_CHECK_XXX calls fails, it reports the location in the wrapper function (which lives in rage_test.cpp):

../../../src/tests/boost_test/rage_test.cpp(20): error in
"km_bodyposemodifier_combo": difference{0.646806%} between
actual.y{3.01940417} and expected.y{3} exceeds 0.100000001%

I would much rather see it unwind another stack frame, and report the location of the CHECK_CLOSE call. How do I do this?

dr. Sybren
  • 829
  • 5
  • 18

1 Answers1

1

You could mutate CHECK_CLOSE into a macro (I know... macros are evil but as wrappers for debug functions, to automatically pass things like __FILE__, __LINE__...)

#if defined(DEBUG)

#define CHECK_CLOSE(actual, expected, tolerance) { \
  if (std::fabs(expected.x) < EPSILON) BOOST_CHECK_SMALL(actual.x, tolerance); \
  else  BOOST_CHECK_CLOSE(actual.x, expected.x, tolerance); \
  if (std::fabs(expected.y) < EPSILON) BOOST_CHECK_SMALL(actual.y, tolerance); \
  else  BOOST_CHECK_CLOSE(actual.y, expected.y, tolerance); \
  if (std::fabs(expected.z) < EPSILON) BOOST_CHECK_SMALL(actual.z, tolerance); \
  else  BOOST_CHECK_CLOSE(actual.z, expected.z, tolerance); \
}

#else

#define CHECK_CLOSE(actual, expected, tolerance)

#endif
manlio
  • 18,345
  • 14
  • 76
  • 126
  • Yeah, I was afraid that this would be the answer... I was hoping I could unwind the call stack somehow to get the appropriate ``__FILE__`` and ``__LINE__``, but it's more likely that ``BOOST_CHECK_CLOSE`` is also a macro itself for this exact reason. – dr. Sybren Mar 15 '14 at 22:34