Gavin Lambert wrote:
If you have API that can take a void* or char* (or other block-of-bytes-of-appropriate-size) and then reinterpret this as a big-endian or little-endian float/double/longdouble (returning the native representation), then this can work and is a useful function. Similarly taking a native float/double/longdouble and writing it to a block-of-bytes in a specified endian format.
"Little-endian float" is not enough information. Floating point formats are not fully described by their endianness. (Neither are integer formats in principle, but in practice they are.) Apart from that, I agree. char[4] /* IEEE 32 bit little endian float */ <-> float is a correct interface. Or even uint32_t <-> float. uint32_t float_to_bits( float x ); float float_from_bits( uint32_t v ); If you have that, you can then byteswap the unit32_t to your heart's content, even though the correct interface there is also char[4] /* little endian 32 bit */ <-> uint32_t.
As a Boost.Endian library user, until the first style of API is implemented you can work around it by doing endian swaps on unsigned integers only, and using a bitwise_cast-equivalent to convert between the floating-point values and unsigned integers of appropriate size.
Something like that, yes, but what I'm suggesting is not a bitwise cast. There need not be any correspondence between the uint32_t bits and the float bits, because the uint32_t is IEEE, and the float is native. Technically, this could also be true for integers; the char[4] representation is 32 bit with no padding and no trapping, and the uint32_t (which would have to be uint_least32_t) may have them. (Although this assumes CHAR_BIT == 8. I'm not sure what is the right interface when CHAR_BIT is 32.)