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

Really re-resolved title level problem

Browse Source 
A few minor edits


[SVN r21634]
This commit is contained in:
Dave Abrahams
2004-01-12 18:02:50 +00:00
parent 129815f3dd
commit b4f1b069be
5 changed files with 65 additions and 59 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
doc/iterator_facade_body.rst
View File

@@ -21,11 +21,11 @@ include the associated types exposed through iterator traits:
``value_type``, ``reference``, ``difference_type``, and
``iterator_category``.
Iterator facade uses the Curiously Recurring Template Pattern (CRTP)
[Cop95]_ so that the user can specify the behavior of
``iterator_facade`` in a derived class. Former designs used policy
objects to specify the behavior. ``iterator_facade`` does not use policy
objects for several reasons:
Iterator facade uses the Curiously Recurring Template
Pattern (CRTP) [Cop95]_ so that the user can specify the behavior
of ``iterator_facade`` in a derived class. Former designs used
policy objects to specify the behavior, but that approach was
discarded for several reasons:
1. the creation and eventual copying of the policy object may create
overhead that can be avoided with the current approach.
@@ -36,9 +36,11 @@ objects for several reasons:
implementations.
3. Without the use of CRTP, the standard requirement that an
iterator's ``operator++`` returns the iterator type itself means
that all iterators generated by ``iterator_facade`` would be
specializations of ``iterator_facade``. Cumbersome type generator
iterator's ``operator++`` returns the iterator type itself
would mean that all iterators built with the library would
have to be specializations of ``iterator_facade<...>``, rather
than something more descriptive like
``indirect_iterator<T*>``. Cumbersome type generator
metafunctions would be needed to build new parameterized
iterators, and a separate ``iterator_adaptor`` layer would be
impossible.
@@ -180,10 +182,10 @@ through ``operator->``. Therefore, an iterator whose ``reference``
type is not in fact a reference must return a proxy containing a copy
of the referenced value from its ``operator->``.
The return type for ``operator->`` and ``operator[]`` is not
explicitly specified. Instead it requires each ``iterator_facade``
specialization to meet the requirements of its ``iterator_category``.
The return types for ``iterator_facade``\ 's ``operator->`` and
``operator[]`` are not explicitly specified. Instead, those types
are described in terms of a set of requirements, which must be
satisfied by the ``iterator_facade`` implementation.
.. [Cop95] [Coplien, 1995] Coplien, J., Curiously Recurring Template
Patterns, C++ Report, February 1995, pp. 24-27.