diff --git a/libs/endian/doc/do_list.html b/libs/endian/doc/do_list.html
index ddefc96..e8ae41c 100644
--- a/libs/endian/doc/do_list.html
+++ b/libs/endian/doc/do_list.html
@@ -15,25 +15,149 @@
Votes
-
-
+ John Filo - "Absolutely. I'd like to see support for float and
+ double, but
+ even without those additions, I still vote yes." "For those who deal with
+ non-native endian data, this library is
+ extremely useful. It automatically eliminates a whole class of common
+ programming errors when dealing with such data."
+
+
-
+
Hartmut Kaiser - "Even if this is not a full review, I would like
+ to vote YES to include this
+ library into Boost.
+
Boost.Spirit is using (and shipping) with an older version of this library
+
+ for several years now and we never had any problems with its usage in
+ Spirit. It is used as the underlying framework for the binary parsers and
+ generators and it is functioning as advertised.
+ As a quick test I replaced the internal (older) version of Boost.Endian in
+
+ Spirit with the reviewed version. All of Spirits regression tests still
+ pass. "
+
+ -
+
Robert Stewart - "There are issues that keep me from saying yes
+ at this time. There are too many suggested variations and ideas under
+ consideration to accept the library in its present state. However, a
+ mini-review should be sufficient to evaluate the final form, once Beman
+ determines a course of action, and determine whether to accept it or not."
+
+ -
+
Tim Blechmann - "the library should be accepted, if
+
+ (a) the interface of the conversion functions is changed
+ (b) the performance can be improved
+ (c) the documentation integrates better with the rest of the boost
+ documentation."
Executive summary
- - Great concern and many suggestions regarding performance
+ - Great concern and many suggestions regarding performance.
- Request for performance benchmarks.
- - Great concern about documentation distinguishing use cases
+ - Great concern about documentation distinguishing use cases and
+ recommendations for which approach (integers vs conversion) is appropriate.
+ - Interest in support for float, double (IEEE754) and user defined types
+ - Either add tutorial or remove from menu bar.
Docs
- Conversion in note mention similarity to htonl() , etc.
+ - Conversion: add discussion of alignment, packing, etc. Bottom line; use at
+ your own risk. Use Phil's example:
+ struct S {
+ uint16_t a;
+ uint32_t b;
+ } __attribute__ ((packed));
+ - Requirements for template parameters.
+ - UDTs
+ - Integers
+ - Conversion
+
+
+ - Distinguish use cases and recommendations for which approach (integers vs
+ conversion) is appropriate.
+
+ - > section `experience': this section gives no insights for people who use
+ or
+ > read the code. it mainly tells: "we are not the first and the domain of the
+ > library is important.". imo this section can be removed (maybe the part that
+ > it is not related to any c library can go to the `design considerations'
+ >
+ > section "motivating use cases": this is more a marketing blurb/testimonial.
+ > maybe this could be changed to a section about possible use cases, listing
+ > `communicating between different devices' and `reading/writing of binary
+ file
+ > formats'.
+ - one other point ... the help file seems to directly link to the c++
+ headers.
+ this should be changed:
+
+ * some browsers (at least chromium) will not display the header when clicking
+ the link, but will save them on disk.
+
+ * providing a direct link to the source code from the docs implies that the
+ user will get some information that are necessary to use the library by
+ reading the sources. imo, this is not the case for using boost.endian.
+
+ * if a user opens integer.hpp, the first 60 lines just contain copyright, some
+ historical notes, compiler-specific stuff, includes and ifdefs. imo, this is
+ the implementation part, which should not be exposed to a user.
+
+ so i'd suggest to completely remove the links to the c++ headers.
Code
- Merge conversion2 into conversion.hpp
+ - Use builtins where applicable (GCC, possibly others)
+ - Endian integer types should use the conversion functions where applicable
+Infrastructure
+
+ - Remove scoped_enum_emulation_test stuff.
+ - Remove timer stuff.
+ - Use Boost.Timer.
+ -
+
+ > endian_operations_test.cpp and endian_in_union_test.cpp ... maybe rename
+ from
+ > _test.cpp to _compile_test.cpp? they don't seem to do any run-time tests.
+ they
+ > also should not include <cassert> since no assertion statement is needed,
+ this
+ > might speed up the compilation time of the testsuite by something like
+ 50ms ;)
+ Will do.
+
+Performance
+
Acknowledge
-Gordon Woodhull, Phil Endecott, tymofey, Giovanni Piero Deretta, Pyry Jahkola
+Gordon Woodhull, Hartmut Kaiser, Phil Endecott, tymofey, Giovanni Piero Deretta, Pyry Jahkola,
+John Filo, Vitaly Budovski, Tomas Puverle, Vicente J. Botet Escriba, Tim
+Blechmann, Daniel James, Mathias Gaunard
+
+Paul Bristow docs help
+
+Floating Point Support
+
+* Because FP formats vary, just dealing with endianness doesn't ensure
+portability.
+* The endianness of FP and integer values differs on some platforms,
+so we will have to build up a config file with separate entries for
+each platform, and that will take time to mature.
+* Ditto FP sizes.
+* I'm only willing to provide conversion.hpp FP support. Providing
+types that mimic FP types is far beyond my knowledge of how to deal
+with floating point's notorious arithmetic issues.
+Support IEEE754 format (32 bit, 64 bit) only.
+
+
+
+
-