On Sat, Apr 9, 2016 at 11:03 PM, Tatsuyuki Ishi
Mr. Beman, Here are some suggestions for the endian library.
1. Bring back float: make a proper reason for abandon You told about NaN: but it shouldn't apply since you store it in char buffer.
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.
Provide a proper reason: float is still needed since this is the only library that wraps details (platform endianness detection+compiler builtin optimizations). Float points are indispensable in data formats. I have to do a reinterpret_cast now as a workaround.
If you can refer me to a precise specification for an external (i.e. on the disk or on the wire) float format bit layout that will work (i.e. round-trip correctly) with actual compilers on a wide range platforms, then please do so. It would ideally be based on some widely accepted existing standard. And it has to be practical to implement. I'm also wondering why there doesn't seem to be existing practice for floats, where there is much existing practice for integers stretching back to the 1970's or earlier.
2. Remove n_bits(endian buffers): completely useless This just look like an alternative to sizeof, and always /8'd when used. What's the meaning of that?
Please give a specific code example from the docs of what you think should be changed. Or submit a pull request.
3. Minor API suggestions Move operator type to endian_buffer: it's not related to arithmetic but just used because it can act like an integer.
Again, what code is it you think should be changed? Operator value_type()? Please submit a pull request.
Non-const data(): I'm tired to do reinterpret_cast. Look at C++11 vector for a reference.
What is the motivation? What are the safety implications? What are the alternatives? The C++11 (and also C++17) addition of non-cost data() members to some standard library containers was supported by motivation and safety analysis.
Move stream operators to endian_arithmetic: I first thought that was for reading binary. That's basically unused.
I must be missing something. Why wouldn't stream operators apply to endian buffers? A code example might help. Thanks, --Beman