On Sat, Jan 24, 2015 at 2:25 AM, Jason Newton wrote: ...

As a long time user of the Boost.Endian library (applying patches to the distribution I maintain), I am happy to see it finally up for uh... mini-review. Hoping to see it get to formal review and included... further hoping it makes it into the next C++ standard!

The library went through formal review in 2011, so will go into Boost as soon as the mini-review is over. And, yes, I do plan to propose it to the standards committee.

It is ready in my opinion. I've seen it go through some topical changes over the years but the only thing I've used from it are the conversion functions which have been great for implementing proper io in the range of network socket io / serial with various protocols and stored data from varies devices/sensors) if a specification enforces byte order. It fullfills my needs and always did fairly well on performance with gcc/clang.

Depending on what version you have been using, the performance may now be even better.

I think the only thing that I have no interest in using - a kind way of saying its probably unneeded bloat IMO is the arithmetic types. I prefer native types and using conversion functions. But maybe they could improve my code - its something I toss back and forth a little and haven't attempted embracing.

Because even the endian buffer and arithmetic types that appear most expensive generate only short sequences of code, the optimizing compilers often generate exactly the same instructions regardless of endian approach. On Intel machines, that often distills down to a single bswap instruction since the value is already in a register. That isn't always true, so you do need to measure performance of various approaches in the context of your actual application. But if use of the buffer or arithmetic types would otherwise improve your code, please don't reject them without actually testing performance first.

This library should not be looked at as fulfilling an uncommon need - and should even be part of future C++ standards because the usual macro/functions (e.g. htons) in the in arpa/inet.h are widely used outside of inet related code (see above examples) and have the types encoded in the name making them not easily usable/composable in contrast to something template based which the library offers. Further IEEE 754 support - especially for double floating point types. The library definitely fills that gap and has for years IMO.

Thanks for the kind words! --Beman