[test] bitwise checks for non-integer types
I was just surprised that BOOST_CHECK_BITWISE_EQUAL does not simply take two memory ranges and compares them bitwise, but requires integers (or types that support bit shifting). I wanted to compare two floats after binary deserialization and wanted to make sure all bits had been placed correctly, before doing value comparison. What I came up with now is a reinterpret_cast to uint8_t* and then using bitwise comparison byte for byte. I would have expected the test framework to do exactly that internally. Is comparing anything besides integers bitwise considered a bad practice or is there another reason for this limitation of BITWISE_EQUAL? If there is a rationale could that be documented at [0], since the documentation currently only speaks of unconstrained "values". thanks, Norbert [0] http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/utf_refer...
On 12/02/2017 22:44, Norbert Wenzel via Boost-users wrote:
I was just surprised that BOOST_CHECK_BITWISE_EQUAL does not simply take two memory ranges and compares them bitwise, but requires integers (or types that support bit shifting). I wanted to compare two floats after binary deserialization and wanted to make sure all bits had been placed correctly, before doing value comparison.
What I came up with now is a reinterpret_cast to uint8_t* and then using bitwise comparison byte for byte. I would have expected the test framework to do exactly that internally.
Is comparing anything besides integers bitwise considered a bad practice or is there another reason for this limitation of BITWISE_EQUAL? If there is a rationale could that be documented at [0], since the documentation currently only speaks of unconstrained "values".
I don't think it's generally considered a good idea to test anything other than integers using bitwise operations, no. (I don't know if this is the rationale for the Boost.Test authors, but it seems likely. Either that or they didn't think anyone would consider it.) Floats, for example, have multiple bit patterns that mean basically the same thing (for NaNs etc) and might get normalised when deserialising, especially when transferring between different CPUs. Structures and classes can contain padding bits/bytes that have no particular guaranteed value (which is why using memcmp will sometimes fail between two copied instances even with a correctly implemented copy constructor).
On 02/13/2017 05:41 AM, Gavin Lambert via Boost-users wrote:
I don't think it's generally considered a good idea to test anything other than integers using bitwise operations, no.
The main advantage of bitwise comparison of integers (compared to operator==) in Boost.Test to me is that the error message clearly says which bit is wrong. I'd prefer this advantage for any type, though I see a reason to not allow this type of comparison (especially for floating point numbers). In case of serialization of arbitrary values a bitwise comparison might come handy, though the workaround with reinterpret_cast is easy enough to do in the rare cases one really wants bitwise comparison for non-integer types. Thanks for your remarks. Norbert
participants (2)
-
Gavin Lambert -
Norbert Wenzel