From: Johan Råde (rade_at_[hidden])
Date: 2006-10-17 03:56:22
Peter Dimov wrote:
> No, the reason compilers do this is because the standard labels accessing a
> float as an int undefined behavior. You can legitimately access it as an
> unsigned char, though, and memcpy'ing a float into an int (under the
> assumption that both are the same size) is also well-defined, although the
> result may have its bytes swapped/reordered if the endianness of the two
> doesn't match. (In practice. In theory it's more complicated.)
Thanks for the information.
I'm a bit worried about the whole endianness issue.
There are three approaches:
1. Check endianness during compile time (using boost/detail/endian.hpp)
2. Check endianness during static initialization (by inspecting the
binary representation of some suitable number)
3. Check endianness each time a function in the library is called (by
inspecting the binary representation of some suitable number)
Alternative 1 is the current approach.
Alternative 2 requires a cpp file and means that the library can not be
used during static initialization.
Alternative 3 is very safe, but slower.
It would be nice to get 1 to work. There are some problems, but are they
real or theoretical?
Any comments on this?
I have uploaded a new version to the vault.
It has more well commented, and it comes bundled with the RC 1.34
version of endian.hpp.
And many thanks to Stephan Tolksdorf, Boris Gubenko and John Maddock
for their improvements to endian.hpp.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk