Subject: Re: [boost] [Review] Boost.Endian mini-review
From: Jason Newton (nevion_at_[hidden])
Date: 2015-01-24 02:25:23
On Fri, Jan 23, 2015 at 8:17 AM, Joel FALCOU <joel.falcou_at_[hidden]> wrote:
> The mini-review of Boost.Endian starts today and runs through Sunday,
> February 1.
> The library repository is available on GitHub at
> The docs for the library can be viewed online at
> The objective of the mini-review is to verify that the issues raised
> during the formal review have been addressed. Those issues are
> documented at https://boostorg.github.io/endian/mini_review_topics.html
> which also describes the resolution of each issue.
> Comments and suggestions unrelated to the mini-review issues are also
> welcome, but the key question the review manager needs your opinion on
> is this:
> Is the library ready to be added to Boost releases?
> -- Joel Falcou, Endian Review Manager
> Unsubscribe & other changes:
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!
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.
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk