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