|
Boost : |
Subject: Re: [boost] [endian] Some suggestions
From: Peter Dimov (lists_at_[hidden])
Date: 2016-04-10 10:01:49
Beman Dawes wrote:
> The problem isn't when storing into the char buffer, but later on a
> different machine or compiler when the char buffer has to be converted to
> a float type.
>
> In testing, I even ran into a case were on the same machine and compiler
> the float data failed to round-trip correctly if the program that created
> the file was compiled with a different set of optimization options that
> the program the read the file.
Perhaps you could go into more detail here, because I'm not sure I
understand the nature of the problem.
Intuitively, if you have a little-endian IEEE platform, and you write the
float out to disk, and then you read that back (even if using different
optimization options), you ought to end up with the same float, because this
is no different than memcpy'ing one float to another.
float x = ..., y;
memcpy( &y, &x, sizeof(float));
// y should contain x
unsigned char buffer[ sizeof(float) ];
memcpy( buffer, &x, sizeof(float));
memcpy( &y, buffer, sizeof(float));
// should be the same as above
unsigned char buffer[ sizeof(float) ];
memcpy( buffer, &x, sizeof(float));
// store buffer to disk
// ...
// load buffer from disk
memcpy( &y, buffer, sizeof(float));
// should be the same as above
At which point do things break?
Furthermore, if the "store buffer" and "load buffer" lines byteswap, this
makes no difference.
Now, if you don't store or load "buffer" but a "float" directly, and then
byteswap that float directly in place, I wouldn't bet on that working. But
there's no need to do so.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk