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).