feedc0de/boost_iterator
1
0
Fork 0
forked from boostorg/iterator
Code Pull Requests Activity

removed counting_iterator paragraph

Browse Source 
added a reply to a comment


[SVN r1216]
This commit is contained in:
Jeremy Siek
2003-04-27 02:52:33 +00:00
parent bc3d6b7c40
commit 6e038bca05
1 changed files with 6 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -66,40 +66,7 @@ random access iterator, but the return type is not ``bool&`` (see
N1185). Therefore, the iterators of ``vector<bool>`` only meet the N1185). Therefore, the iterators of ``vector<bool>`` only meet the
requirements of input iterator and output iterator. This is so requirements of input iterator and output iterator. This is so
nonintuitive that at least one implementation erroneously assigns nonintuitive that at least one implementation erroneously assigns
``random_access_iterator_tag`` as its ``iterator_category``. Also, ``random_access_iterator_tag`` as its ``iterator_category``.
``vector<bool>`` is not the only example of useful iterators that do
not return true references: there is the often cited example of
disk-based collections.
.. I wonder if the disk-based collection argument is valid? I would
tend to do that with an internally stored lvalue. -DWA
.. _issue 96: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#96
.. Another example of a hard-to-categorize iterator is a counting
iterator: an iterator the returns a sequence of integers when
incremented and dereferenced (see counting_iterator_). This iterator are two
ways to implement this iterator, 1) return a true reference from
``operator[]`` (a reference to an integer data member of the counting
iterator) or 2) return the ``value_type`` or a proxy from
``operator[]``. Option 1) runs into the problems discussed in `issue
198`_: the reference will not be valid after the iterator is
destroyed. Option 2) is therefore a better choice, but then we have a
counting iterator that cannot be a random access iterator.
.. Jeremy, option 1 is NOT an option, since there's no way to return a
live reference from operator[]. I think you need to clarify/rework
what you're saying here. I'd fix it myself, but I'm not sure what
you're getting at. -DWA
.. On second thought, I think the whole paragraph is bogus (sorry).
The conclusion for option 2, "but then we have a counting iterator
that cannot be a random access iterator" is wrong, too: returning a
value from operator[] is compatible with the random access iterator
requirements. I commented it out. -DWA
.. _counting_iterator: http://www.boost.org/libs/utility/counting_iterator.htm
.. _issue 198: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/lwg-active.html#198
Another difficult-to-categorize iterator is the transform iterator, an Another difficult-to-categorize iterator is the transform iterator, an
adaptor which applies a unary function object to the dereferenced adaptor which applies a unary function object to the dereferenced
@@ -153,6 +120,11 @@ appropriate old requirements.
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
made it). -DWA made it). -DWA
.. Hmm, not sure I understand. Are you talking about whether a
standards conforming input iterator is allowed to have
a tag that is not input_iterator_tag but that
is convertible to input_iterator_tag? -JGS
The algorithms in the standard library benefit from the new iterator The algorithms in the standard library benefit from the new iterator
concepts because the new concepts provide a more accurate way to concepts because the new concepts provide a more accurate way to
express their type requirements. The result is algorithms that are express their type requirements. The result is algorithms that are