Re: [boost] [endian] Some suggestions

Subject: Re: [boost] [endian] Some suggestions
From: Beman Dawes (bdawes_at_[hidden])
Date: 2016-04-10 09:18:23

On Sat, Apr 9, 2016 at 11:03 PM, Tatsuyuki Ishi <ishitatsuyuki_at_[hidden]>
wrote:

> 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