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.) The primary focus is on native types (int types initially, and we're discussing extending that to float types as well) and that's all I'd expect from an initial version of the library. But it would be useful (not mandatory, just convenient) if another library or application could hook into the design to extend it to support additional types as I mentioned. But that was just an aside, a "would be nice to keep this in mind".