As presented in ABQ

This commit is contained in:
Beman
2017-11-10 15:27:21 -07:00
parent a2b044f181
commit af744e9485

View File

@@ -25,12 +25,12 @@ body
<table> <table>
<tr> <tr>
<td align="left">Doc. no.:</td> <td align="left">Doc. no.:</td>
<td align="left">P0803R0</td> <td align="left">D0803R1</td>
</tr> </tr>
<tr> <tr>
<td align="left">Date:</td> <td align="left">Date:</td>
<td align="left"> <td align="left">
<!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2017-10-15<!--webbot bot="Timestamp" endspan i-checksum="12057" --></td> <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%Y-%m-%d" startspan -->2017-11-10<!--webbot bot="Timestamp" endspan i-checksum="12111" --></td>
</tr> </tr>
<tr> <tr>
<td align="left">Reply to:</td> <td align="left">Reply to:</td>
@@ -44,7 +44,7 @@ body
<h1 align="center">Endian Library Request for Comments (R0)</h1> <h1 align="center">Endian Library Request for Comments (R1)</h1>
<h2>Abstract</h2> <h2>Abstract</h2>
@@ -52,8 +52,10 @@ body
<a href="https://en.wikipedia.org/wiki/Endianness">endianness</a> of integers <a href="https://en.wikipedia.org/wiki/Endianness">endianness</a> of integers
and user-defined types. It provides three approaches to dealing with endianness: and user-defined types. It provides three approaches to dealing with endianness:
conversion functions, buffer classes, and arithmetic classes. Each approach conversion functions, buffer classes, and arithmetic classes. Each approach
has use cases where it is preferred over the other approaches. The purpose of has use cases where it is preferred by users over the other approaches, but
this RFC is to determine interest in adding all or any of these components to adding all three approaches to the standard library would likely be too much of
a good thing. The purpose of
this RFC is to determine interest in adding the Boost conversion functions alone to
the C++ standard library or a library TS.</p> the C++ standard library or a library TS.</p>
<h2>Introduction</h2> <h2>Introduction</h2>
<p>The Boost Endian documentation (<a href="https://www.boost.org/libs/endian/doc/index.html">www.boost.org/libs/endian/doc</a>) <p>The Boost Endian documentation (<a href="https://www.boost.org/libs/endian/doc/index.html">www.boost.org/libs/endian/doc</a>)
@@ -75,51 +77,55 @@ Arithmetic FAQ</a>, and
<a href="https://www.boost.org/libs/endian/doc/buffers.html#FAQ">Buffers FAQ</a> <a href="https://www.boost.org/libs/endian/doc/buffers.html#FAQ">Buffers FAQ</a>
answer a lot of question likely to arise during standardization.</p> answer a lot of question likely to arise during standardization.</p>
<h2>Motivation for standardization</h2> <h2>Motivation for standardization</h2>
<ul> Lack of any one de facto standard endianness capability in either C or
<li>Lack of any one de facto standard endianness capability in either C or
C++. While most platforms provides some way to handle endianness in C, the C++. While most platforms provides some way to handle endianness in C, the
mechanism varies from platform to platform.</li> mechanism varies from platform to platform.<ul>
<li>Commonly used endian handling functions are extremely error prone. While <li>Commonly used C endian handling functions are extremely error prone. While
the Boost Endian conversion functions have the same problems, the buffer and the Boost Endian conversion functions have some of the same problems, the buffer and
arithmetic classes do not.</li> arithmetic classes do not.</li>
<li>Surprisingly difficult to write and test yourself in a portable yet <li>Surprisingly difficult to write and test yourself in a portable yet
efficient (i.e. using intrinsics) way. </li> efficient (i.e. using intrinsics) way. </li>
<li>Explicit requests for standardization from Boost Endian users.</li> <li>Explicit requests for standardization from Boost Endian users.</li>
<li>The Boost library is existing practice with years of both implementation <li>The Boost library is existing practice with years of both implementation
and end-user experience.</li> and end-user experience.</li>
<li>The committee has already failed once to standardize endian conversion <li>The committee has already started to standardize endian conversion
functions; perhaps now is time to do it right.</li> functions once, but had to pull the proposal at the last minute because of
name clashes with widely used macros.</li>
</ul>
<h2>Motivation for standardizing only the conversion functions</h2>
<ul>
<li>KISS; Providing three different solutions to the same problem space
regularly confuses to Boost users and makes endianness solutions harder to
teach.</li>
<li>The conversion functions are what end users would need to build their own
higher level abstractions.</li>
<li>The safe use patterns for the conversion functions are already familiar to
users of platform specific C endian conversion functions.</li>
<li>The Boost buffer and arithmetic types are specified and implemented in
terms of the conversion functions, so are easy to add later if desired.</li>
</ul> </ul>
<h2>Impact on the standard library</h2> <h2>Impact on the standard library</h2>
<p>All three proposed approaches to endianness would be a pure additions to the <p>Endianness conversion functions would be pure additions to the
standard library and would break no existing user code (modulo the usual standard library and would break no existing user code (modulo the usual
namespace caveats).</p> namespace <code>std</code> caveats).</p>
<h2>Proposed wording</h2> <h2>Proposed wording</h2>
<p>The Boost Endian reference documentation for <p>The Boost Endian reference documentation for
<a href="https://www.boost.org/libs/endian/doc/conversion.html#Reference"> <a href="https://www.boost.org/libs/endian/doc/conversion.html#Reference">
Conversion</a>, Conversion</a> follows the standard library&#39;s <i>Method of description</i>
<a href="https://www.boost.org/libs/endian/doc/arithmetic.html#endian">
Arithmetic</a>, and
<a href="https://www.boost.org/libs/endian/doc/buffers.html#endian">Buffer</a>
approaches follows the standard library&#39;s <i>Method of description</i>
[description], so provides a fairly close approximation of what proposed wording [description], so provides a fairly close approximation of what proposed wording
would look like. Actual proposed wording will be provided in a proposal document would look like. Actual proposed wording will be provided in a proposal document
for any portions of the library of interest to the committee. Names will need if the library is of interest to the committee. Names will need
the usual bikeshedding.</p> the usual review.</p>
<h2>Questions for the Library Evolution Group</h2> <h2>Revision history</h2>
<ul> <p>R1: Limits proposal to the conversion functions. KISS.</p>
<li>How would you likely vote on a fully-worded and reviewed proposal to add a <p>R0: Considers adding all three endianness approaches to the standard library.</p>
<h2>Question for the Library Evolution Group</h2>
Assuming a fully-worded and reviewed proposal to add a
standardized version of the Boost Endian conversion functions to the standard standardized version of the Boost Endian conversion functions to the standard
library or a library TS?<br> library or a library TS, how would you likely vote for it?<h2>Target?</h2>
&nbsp;</li> <p>It is premature to discuss whether to target a TS or the IS. We need to have
<li>How would you likely vote on a fully-worded and reviewed proposal to add a an acceptable proposal in hand and see where we are in the release cycle before
standardized version of the Boost Endian buffer classes to the standard deciding on the target. </p>
library or a library TS?<br>
&nbsp;</li>
<li>How would you likely vote on a fully-worded and reviewed proposal to add a
standardized version of the Boost Endian arithmetic classes to the standard
library or a library TS?</li>
</ul>
<h2>Acknowledgements</h2> <h2>Acknowledgements</h2>
<p>The original design for the arithmetic classes was developed by Darin Adler <p>The original design for the arithmetic classes was developed by Darin Adler
based on work by Mark Borgerding. The Boost documentation acknowledges based on work by Mark Borgerding. The Boost documentation acknowledges