diff --git a/doc/index.html b/doc/index.html
index bdd5c38..033dd98 100644
--- a/doc/index.html
+++ b/doc/index.html
@@ -45,6 +45,7 @@
Timings
Conclusions
FAQ
+ Release history
Acknowledgements
@@ -302,6 +303,11 @@ big_endian(x);
+With the Endian type approach, an implicit conversion from and then back to
+big endian is done inside the loop. With the Endian conversion function
+approach, the conversions are explicit, so only need to be done once, before and
+after the loop.
+
Timings for Example 2 (conversion functions hoisted
out of loop)
These tests were run against release builds on a circa 2012 4-core little endian X64 Intel Core i5-3570K
@@ -426,8 +432,8 @@ times while the Endian conversion approach only does the reversal once. But if
the endianness is the same, there is no conversion with either approach and no
conversion code is generated for typical release builds.
-Whether or not compiler byte swap intrinsics are available has little
-impact. Byte swap intrinsics are not available on some older
+
Whether or not compiler byte swap intrinsics are explicitly available has little
+impact as tested. Byte swap intrinsics are not available on some older
compilers and on some machine architectures, such as pre-486 X86 CPUs.
Unaligned types are much slower that aligned types, regardless of
@@ -515,6 +521,45 @@ performed on machines that use two's complement arithmetic.
+
+Changes since formal review
+
+ - Headers have been renamed to endian/types.hpp and endian/conversion.hpp.
+ Infrastructure file names were changed accordingly.
+ - The endian types and endian conversion functions now support 32-bit (
float)
and
+ 64-bit (double)
floating point, as requested.
+ - Both the endian types and endian conversion functions now support UDTs, as requested.
+ - The endian type aliases have been renamed,
+ using a naming pattern that is consistent for both integer and floating point,
+ and that emphasizes that aligned types are usually preferred compared to
+ unaligned types. Unaligned types are deliberately given slightly uglier names.
+ - The conversion functions have been much revised,
+ refactored, and otherwise improved based on review comments.
+ - Functions have been renamed to clarify their functionality.
+ - Both return-by-value and modify-in-place interfaces are provided, as
+ requested.
+ - Synonyms for the BSD byte swapping function names popularized by OS X
+ and Linux are provided, so that that developers already used to these name
+ can continue to use them if they wish.
+ - In addition to the named-endianness functions, functions that perform
+ compile-time (via template) and run-time (via function argument) dispatch
+ are now provided, as requested.
+
+
+ - Compiler (Clang, GCC, VisualC++, etc.) intrinsics and built-in functions
+ are used in the implementation where appropriate, as requested.
+ - For the endian types, the implementation uses the endian conversion functions,
+ and thus the intrinsics,
+ as requested.
+ - C++11 features such as
noexcept
are now used, while still
+ supporting C++03 compilers.
+ - Acknowledgements have been updated.
+ - Headers have been reorganized to make them easier to read,
+ with a synopsis at the front and implementation following, as requested.
+ - Documentation has been revised to address most, but not all, concerns
+ raised during formal review.
+
+
Comments and suggestions were
received from