feedc0de/boost_endian
1
0
Fork 0
forked from boostorg/endian
Code Pull Requests Activity

As presented in ABQ

Browse Source
This commit is contained in:
Beman
2017-11-10 15:27:21 -07:00
parent a2b044f181
commit af744e9485
1 changed files with 40 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
doc/std-rfc.html
View File

@@ -25,12 +25,12 @@ body
<table>
<tr>
<td align="left">Doc. no.:</td>
<td align="left">P0803R0</td>
<td align="left">D0803R1</td>
</tr>
<tr>
<td align="left">Date:</td>
<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>
<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>
@@ -52,8 +52,10 @@ body
<a href="https://en.wikipedia.org/wiki/Endianness">endianness</a> of integers
and user-defined types. It provides three approaches to dealing with endianness:
conversion functions, buffer classes, and arithmetic classes. Each approach
has use cases where it is preferred over the other approaches. The purpose of
this RFC is to determine interest in adding all or any of these components to
has use cases where it is preferred by users over the other approaches, but
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>
<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>)
@@ -75,51 +77,55 @@ Arithmetic FAQ</a>, and
<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>
<h2>Motivation for standardization</h2>
<ul>
<li>Lack of any one de facto standard endianness capability in either C or
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
mechanism varies from platform to platform.</li>
<li>Commonly used endian handling functions are extremely error prone. While
the Boost Endian conversion functions have the same problems, the buffer and
mechanism varies from platform to platform.<ul>
<li>Commonly used C endian handling functions are extremely error prone. While
the Boost Endian conversion functions have some of the same problems, the buffer and
arithmetic classes do not.</li>
<li>Surprisingly difficult to write and test yourself in a portable yet
efficient (i.e. using intrinsics) way. </li>
<li>Explicit requests for standardization from Boost Endian users.</li>
<li>The Boost library is existing practice with years of both implementation
and end-user experience.</li>
<li>The committee has already failed once to standardize endian conversion
functions; perhaps now is time to do it right.</li>
<li>The committee has already started to standardize endian conversion
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>
<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
namespace caveats).</p>
namespace <code>std</code> caveats).</p>
<h2>Proposed wording</h2>
<p>The Boost Endian reference documentation for
<a href="https://www.boost.org/libs/endian/doc/conversion.html#Reference">
Conversion</a>,
<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>
Conversion</a> follows the standard library&#39;s <i>Method of description</i>
[description], so provides a fairly close approximation of what proposed wording
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
the usual bikeshedding.</p>
<h2>Questions for the Library Evolution Group</h2>
<ul>
<li>How would you likely vote on a fully-worded and reviewed proposal to add a
if the library is of interest to the committee. Names will need
the usual review.</p>
<h2>Revision history</h2>
<p>R1: Limits proposal to the conversion functions. KISS.</p>
<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
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 buffer classes to the standard
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>
library or a library TS, how would you likely vote for it?<h2>Target?</h2>
<p>It is premature to discuss whether to target a TS or the IS. We need to have
an acceptable proposal in hand and see where we are in the release cycle before
deciding on the target. </p>
<h2>Acknowledgements</h2>
<p>The original design for the arithmetic classes was developed by Darin Adler
based on work by Mark Borgerding. The Boost documentation acknowledges