Subject: Re: [boost] [endian] Project not maintained
From: Peter Dimov (lists_at_[hidden])
Date: 2016-04-04 07:54:14
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 /* 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 /* 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
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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk