1//// 2Copyright 2011-2016 Beman Dawes 3 4Distributed under the Boost Software License, Version 1.0. 5(http://www.boost.org/LICENSE_1_0.txt) 6//// 7 8[#appendix_history] 9[appendix] 10# History and Acknowledgments 11:idprefix: apph_ 12 13## History 14 15### Changes requested by formal review 16 17The library was reworked from top to bottom to accommodate changes requested 18during the formal review. The issues that were required to be resolved before 19a mini-review are shown in *bold* below, with the resolution indicated. 20 21Common use case scenarios should be developed.:: 22Done. The documentation have been refactored. A page is now devoted to 23<<choosing,Choosing the Approach>> to endianness. See 24<<choosing_use_cases,Use cases>> for use case scenarios. 25 26Example programs should be developed for the common use case scenarios.:: 27Done. See <<choosing,Choosing the Approach>>. Example code has been added 28throughout. 29 30Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications.:: 31Done. See <<choosing,Choosing the Approach>>. 32 33Conversion functions supplying results via return should be provided.:: 34Done. See <<conversion,Conversion Functions>>. 35 36Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported.:: 37Done. Compiler (Clang, GCC, Visual{cpp}, etc.) intrinsics and built-in 38functions are used in the implementation where appropriate, as requested. See 39<<overview_intrinsic,Built-in support for Intrinsics>>. See 40<<overview_timings,Timings for Example 2>> to gauge the impact of intrinsics. 41 42Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies.:: 43Done. For the endian types, the implementation uses the endian conversion 44functions, and thus the intrinsics, as requested. 45 46Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios.:: 47Done. See <<overview_timings,Timings for Example 2>>. The `endian/test` 48directory also contains several additional benchmark and speed test programs. 49 50Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case.:: 51Done. The <<buffers,endian buffer types>>, 52<<arithmetic,endian arithmetic types>> and 53<<conversion,endian conversion functions>> now support 32-bit `(float)` 54and 64-bit `(double)` floating point, as requested. 55 56NOTE: This answer is outdated. The support for `float` and `double` was subsequently found 57 problematic and has been removed. Recently, support for `float` and `double` has 58 been reinstated for `endian_buffer` and `endian_arithmetic`, but not for the 59 conversion functions. 60 61Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns.:: 62Done. See <<conversion_customization,Customization points for user-defined 63types (UDTs)>>. 64 65There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated.:: 66Done. The endian types have been decomposed into class template 67`<<buffers,endian_buffer>>` and class template 68`<<arithmetic,endian_arithmetic>>`. Class `endian_buffer` is a public base 69class for `endian_arithmetic`, and can also be used by users as a stand-alone 70class. 71 72Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage.:: 73Done. See <<buffers_stream_inserter,Stream inserter>> and 74<<buffers_stream_extractor,Stream extractor>>. 75 76Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library.:: 77Not done yet. Will be handled as a separate min-review soon after the Endian 78mini-review. 79 80Other requested changes.:: 81* In addition to the named-endianness conversion functions, functions that 82 perform compile-time (via template) and run-time (via function argument) 83 dispatch are now provided. 84* `order::native` is now a synonym for `order::big` or `order::little` according 85 to the endianness of the platform. This reduces the number of template 86 specializations required. 87* Headers have been reorganized to make them easier to read, with a synopsis 88 at the front and implementation following. 89 90### Other changes since formal review 91 92* Header `boost/endian/endian.hpp` has been renamed to 93`boost/endian/arithmetic.hpp`. Headers 94`boost/endian/conversion.hpp` and `boost/endian/buffers.hpp` have been added. 95Infrastructure file names were changed accordingly. 96* The endian arithmetic type aliases have been renamed, using a naming pattern 97that is consistent for both integer and floating point, and a consistent set of 98aliases supplied for the endian buffer types. 99* The unaligned-type alias names still have the `_t` suffix, but the 100aligned-type alias names now have an `_at` suffix. 101* `endian_reverse()` overloads for `int8_t` and `uint8_t` have been added for 102improved generality. (Pierre Talbot) 103* Overloads of `endian_reverse_inplace()` have been replaced with a single 104`endian_reverse_inplace()` template. (Pierre Talbot) 105* For X86 and X64 architectures, which permit unaligned loads and stores, 106unaligned little endian buffer and arithmetic types use regular loads and 107stores when the size is exact. This makes unaligned little endian buffer and 108arithmetic types significantly more efficient on these architectures. (Jeremy 109Maitin-Shepard) 110* {cpp}11 features affecting interfaces, such as `noexcept`, are now used. 111{cpp}03 compilers are still supported. 112* Acknowledgements have been updated. 113 114## Compatibility with interim releases 115 116Prior to the official Boost release, class template `endian_arithmetic` has been 117used for a decade or more with the same functionality but under the name 118`endian`. Other names also changed in the official release. If the macro 119`BOOST_ENDIAN_DEPRECATED_NAMES` is defined, those old now deprecated names are 120still supported. However, the class template `endian` name is only provided for 121compilers supporting {cpp}11 template aliases. For {cpp}03 compilers, the name 122will have to be changed to `endian_arithmetic`. 123 124To support backward header compatibility, deprecated header 125`boost/endian/endian.hpp` forwards to `boost/endian/arithmetic.hpp`. It requires 126`BOOST_ENDIAN_DEPRECATED_NAMES` be defined. It should only be used while 127transitioning to the official Boost release of the library as it will be removed 128in some future release. 129 130## Future directions 131 132Standardization.:: 133The plan is to submit Boost.Endian to the {cpp} standards committee for possible 134inclusion in a Technical Specification or the {cpp} standard itself. 135 136Specializations for `numeric_limits`.:: 137Roger Leigh requested that all `boost::endian` types provide `numeric_limits` 138specializations. 139See https://github.com/boostorg/endian/issues/4[GitHub issue 4]. 140 141Character buffer support.:: 142Peter Dimov pointed out during the mini-review that getting and setting basic 143arithmetic types (or `<cstdint>` equivalents) from/to an offset into an array of 144unsigned char is a common need. See 145http://lists.boost.org/Archives/boost/2015/01/219574.php[Boost.Endian 146mini-review posting]. 147 148Out-of-range detection.:: 149Peter Dimov pointed suggested during the mini-review that throwing an exception 150on buffer values being out-of-range might be desirable. See the end of 151http://lists.boost.org/Archives/boost/2015/01/219659.php[this posting] and 152subsequent replies. 153 154## Acknowledgements 155 156Comments and suggestions were received from Adder, Benaka Moorthi, Christopher 157Kohlhoff, Cliff Green, Daniel James, Dave Handley, Gennaro Proto, Giovanni Piero 158Deretta, Gordon Woodhull, dizzy, Hartmut Kaiser, Howard Hinnant, Jason Newton, 159Jeff Flinn, Jeremy Maitin-Shepard, John Filo, John Maddock, Kim Barrett, Marsh 160Ray, Martin Bonner, Mathias Gaunard, Matias Capeletto, Neil Mayhew, Nevin Liber, 161Olaf van der Spek, Paul Bristow, Peter Dimov, Pierre Talbot, Phil Endecott, 162Philip Bennefall, Pyry Jahkola, Rene Rivera, Robert Stewart, Roger Leigh, Roland 163Schwarz, Scott McMurray, Sebastian Redl, Tim Blechmann, Tim Moore, tymofey, 164Tomas Puverle, Vincente Botet, Yuval Ronen and Vitaly Budovsk. Apologies if 165anyone has been missed. 166 167The documentation was converted into Asciidoc format by Glen Fernandes. 168