boostorg/iterator
1
0
Fork 1
mirror of https://github.com/boostorg/iterator.git synced 2025-07-21 16:42:09 +02:00
Code Issues Packages Projects Releases Wiki Activity

moved a paragraph about algorithm changes

Browse Source 
[SVN r21043]
This commit is contained in:
Jeremy Siek
2003-12-01 15:02:48 +00:00
parent cc282d81c0
commit 8cfa950f10
1 changed files with 12 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
doc/new-iter-concepts.rst
View File

@ -130,15 +130,13 @@ things happen:
Impact on the Standard Impact on the Standard
======================== ========================
Proposed Changes for TR1 This proposal for TR1 is a pure extension. Further, the new iterator
======================== concepts are backward-compatible with the old iterator requirements,
and old iterators are forward-compatible with the new iterator
The new iterator concepts are backward-compatible with the old concepts. That is to say, iterators that satisfy the old requirements
iterator requirements, and old iterators are forward-compatible with also satisfy appropriate concepts in the new system, and iterators
the new iterator concepts. That is to say, iterators that satisfy the modeling the new concepts will automatically satisfy the appropriate
old requirements also satisfy appropriate concepts in the new system, old requirements.
and iterators modeling the new concepts will automatically satisfy the
appropriate old requirements.
.. I think we need to say something about the resolution to allow .. I think we need to say something about the resolution to allow
convertibility to any of the old-style tags as a TR issue (hope it convertibility to any of the old-style tags as a TR issue (hope it
@ -149,11 +147,6 @@ appropriate old requirements.
a tag that is not input_iterator_tag but that a tag that is not input_iterator_tag but that
is convertible to input_iterator_tag? -JGS is convertible to input_iterator_tag? -JGS
The algorithms in the standard library benefit from the new iterator
concepts because the new concepts provide a more accurate way to
express their type requirements. The result is algorithms that are
usable in more situations and have fewer type requirements.
Note that as currently specified, ``istreambuf_iterator`` doesn't Note that as currently specified, ``istreambuf_iterator`` doesn't
meet the Readable Iterator requirements because its ``value_type`` meet the Readable Iterator requirements because its ``value_type``
is not convertible to its ``reference`` type. We believe this to is not convertible to its ``reference`` type. We believe this to
@ -170,6 +163,11 @@ a formal part of this proposal for TR1.
Changes to Algorithm Requirements Changes to Algorithm Requirements
+++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++
The algorithms in the standard library could benefit from the new
iterator concepts because the new concepts provide a more accurate way
to express their type requirements. The result is algorithms that are
usable in more situations and have fewer type requirements.
For the next working paper (but not for TR1), the committee should For the next working paper (but not for TR1), the committee should
consider the following changes to the type requirements of consider the following changes to the type requirements of
algorithms. These changes are phrased as phrased as textual algorithms. These changes are phrased as phrased as textual