]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | <html> |
2 | ||
3 | <head> | |
4 | <meta http-equiv="Content-Language" content="en-us"> | |
5 | <meta name="GENERATOR" content="Microsoft FrontPage 5.0"> | |
6 | <meta name="ProgId" content="FrontPage.Editor.Document"> | |
7 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | |
8 | <title>Endian Library Do List</title> | |
9 | </head> | |
10 | ||
11 | <body> | |
12 | ||
13 | <h1>Endian Library TODO List</h1> | |
14 | ||
15 | <h2>To Do</h2> | |
16 | <h2>Format Review Comments</h2> | |
17 | <h3 dir="ltr">Interesting</h3> | |
18 | <ul> | |
19 | <li dir="ltr"> | |
20 | <p dir="ltr">John Filo - "Absolutely. I'd like to see support for float and | |
21 | double, but<br> | |
22 | even without those additions, I still vote yes." "For those who deal with | |
23 | non-native endian data, this library is<br> | |
24 | extremely useful. It automatically eliminates a whole class of common<br> | |
25 | programming errors when dealing with such data."<br> | |
26 | </li> | |
27 | <li dir="ltr"> | |
28 | <p dir="ltr">Hartmut Kaiser - "Even if this is not a full review, I would like | |
29 | to vote YES to include this <br> | |
30 | library into Boost. | |
31 | <p>Boost.Spirit is using (and shipping) with an older version of this library | |
32 | <br> | |
33 | for several years now and we never had any problems with its usage in <br> | |
34 | Spirit. It is used as the underlying framework for the binary parsers and <br> | |
35 | generators and it is functioning as advertised.</p> | |
36 | <p>As a quick test I replaced the internal (older) version of Boost.Endian in | |
37 | <br> | |
38 | Spirit with the reviewed version. All of Spirits regression tests still <br> | |
39 | pass. "<br> | |
40 | </li> | |
41 | </ul> | |
42 | <h3>Executive summary</h3> | |
43 | <ul> | |
44 | <li>Common use case scenarios should be developed.</li> | |
45 | <li>Example programs should be developed for the common use case scenarios.</li> | |
46 | <li>Documentation should illuminate the differences between endian | |
47 | integer/float type and endian conversion approaches to the common use case | |
48 | scenarios, and provide guidelines for choosing the most appropriate approach | |
49 | for user's applications.</li> | |
50 | <li>Conversion functions supplying results via <code>return</code> should be | |
51 | provided.</li> | |
52 | <li>Platform specific performance enhancements such as use of compiler | |
53 | intrinsics or relaxed alignment requirements should be supported.</li> | |
54 | <li>Endian integer (and floating) types should be implemented via the | |
55 | conversion functions. If that can't be done efficiently, consideration should | |
56 | be given to expanding the conversion function signatures to resolve the | |
57 | inefficiencies.</li> | |
58 | <li>Benchmarks that measure performance should be provided. It should be | |
59 | possible to compare platform specific performance enhancements against | |
60 | portable base implementations, and to compare endian integer approaches | |
61 | against endian conversion approaches for the common use case scenarios.</li> | |
62 | <li>Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the | |
63 | primary use case.</li> | |
64 | <li>Support for user defined types (UDTs) is desirable, and should be | |
65 | supported where there would be no conflict with the other concerns.</li> | |
66 | <li>There is some concern that endian integer/float arithmetic operations | |
67 | might used | |
68 | inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic | |
69 | operations should be investigated.</li> | |
70 | <li>Stream insertion and extraction of the endian integer/float types should | |
71 | be documented and included in the test coverage.</li> | |
72 | <li>Binary I/O support that was investigated during development of the Endian | |
73 | library should be put up for min-review for inclusion in the Boost I/O | |
74 | library.</li> | |
75 | </ul> | |
76 | <h3>Docs</h3> | |
77 | <ul> | |
78 | <li>one other point ... the help file seems to directly link to the c++ | |
79 | headers.<br> | |
80 | this should be changed:<br> | |
81 | <br> | |
82 | * some browsers (at least chromium) will not display the header when clicking<br> | |
83 | the link, but will save them on disk.<br> | |
84 | <br> | |
85 | * providing a direct link to the source code from the docs implies that the<br> | |
86 | user will get some information that are necessary to use the library by<br> | |
87 | reading the sources. imo, this is not the case for using boost.endian.<br> | |
88 | <br> | |
89 | * if a user opens integer.hpp, the first 60 lines just contain copyright, some<br> | |
90 | historical notes, compiler-specific stuff, includes and ifdefs. imo, this is<br> | |
91 | the implementation part, which should not be exposed to a user.<br> | |
92 | <br> | |
93 | so i'd suggest to completely remove the links to the c++ headers.<br> | |
94 | </li> | |
95 | </ul> | |
96 | <hr> | |
97 | <p>Last revised: | |
98 | <!--webbot bot="Timestamp" s-type="EDITED" s-format="%d %B, %Y" startspan -->17 January, 2015<!--webbot bot="Timestamp" endspan i-checksum="38899" --></p> | |
99 | <p>© Copyright Beman Dawes, 2012</p> | |
100 | <p>Distributed under the Boost Software License, Version 1.0. See | |
101 | <a href="http://www.boost.org/LICENSE_1_0.txt">www.boost.org/LICENSE_1_0.txt</a></p> | |
102 | <p> </p> | |
103 | ||
104 | </body> | |
105 | ||
106 | </html> |