Re: [boost] [endian] Project not maintained

Subject: Re: [boost] [endian] Project not maintained
From: Rob Stewart (rstewart_at_[hidden])
Date: 2016-04-05 04:36:36

On April 5, 2016 12:18:53 AM EDT, Gavin Lambert <gavinl_at_[hidden]> wrote:
>On 5/04/2016 15:48, Michael Caisse wrote:
>> Expect that we would no longer be talking endianess and those
>> conversions in a Boost.Endian library would be odd at best.
>
>I think you missed my point about "endianness" just being a way to 
>define a particular storage format (byte layout) for integers.
>
>Other types have other properties (floats have both endianness and IEEE
>layout vs. other layouts, for example).
>
>(Even endianness itself isn't limited to big vs. little as some people 
>think -- some architectures use a mixed format, although hopefully
>those are less likely to end up in serialisation formats.)
>
>Ultimately though it's all just specifying a 
>host-architecture-independent storage format (bit layout) for a given
>type.
>
>The purpose of Boost.Endian is to be able to take a block-of-bytes in 
>such an explicitly specified format and convert it to the native 
>representation of the value, and the reverse.  (Note that this process 
>might be more complex than just a byte swap in some cases.)

That's quite a leap from what I see in the docs and what has been meant traditionally by such facilities. In my experience, endianness was all about but swapping of otherwise compatible binary data representations. Anything more is serialization or marshalling. The difference is performance.

I'll grant that a well-defined wire format would increase portability, and a well-chosen format would imply very little data manipulation for common platforms, but that exceeds the scope of and endian library. At that point, we're talking Boost.Exchange or something.

___
Rob

(Sent from my portable computation engine)