On Fri, Jan 23, 2015 at 8:17 AM, Joel FALCOU
The mini-review of Boost.Endian starts today and runs through Sunday, February 1.
The library repository is available on GitHub at https://github.com/boostorg/endian
The docs for the library can be viewed online at https://boostorg.github.io/endian/
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: http://lists.boost.org/mailman/listinfo.cgi/boost
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 attempted embracing. 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. Best Regards, -Jason