Re: [boost] [Review] Boost.Endian mini-review

Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2015-01-25 11:21:57

On Sat, Jan 24, 2015 at 2:25 AM, Jason Newton <nevion_at_[hidden]> 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