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

edits

Browse Source 
[SVN r1206]
This commit is contained in:
Dave Abrahams
2003-04-26 17:59:56 +00:00
parent ee71d493b6
commit b15439a2a4
1 changed files with 28 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

55
doc/facade-and-adaptor.rst
View File

@@ -121,17 +121,16 @@ Iterator Concepts.
Iterator Concepts Iterator Concepts
================= =================
This proposal is formulated in terms of the new ``iterator concepts`` This proposal is formulated in terms of the new ``iterator concepts``
as proposed in `n1477`_. This is due to the fact that especially as proposed in `n1477`_, since user-defined and especially adapted
adapted and user defined iterators suffer from the well known iterators suffer from the well known categorisation problems that are
categorisation problems that are inherent to the current iterator inherent to the current iterator categories.
categories.
.. _`n1477`: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1477.html .. _`n1477`: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1477.html
Though this proposal does not strictly depend on proposal `n1477`_, This proposal does not strictly depend on proposal `n1477`_, as there
as there is a direct mapping between new and old categories. The proposal is a direct mapping between new and old categories. This proposal
could be reformulated using this mapping. could be reformulated using this mapping if `n1477`_ was not accepted.
Interoperability Interoperability
================ ================
@@ -280,14 +279,14 @@ operator->()
============ ============
For ``readable iterators`` the reference type is only required to be For ``readable iterators`` the reference type is only required to be
convertible to the value type. Though accessing members through convertible to the value type, but accessing members through
``operator->()`` must still be possible. As a result a conformant ``operator->()`` must still be possible. As a result a conformant
``readable iterator`` needs to return a proxy from ``operator->()``. ``readable iterator`` must return a proxy from ``operator->()``.
This proposal does not explicitly specify the return type for This proposal does not explicitly specify the return type for
``operator->()`` and ``operator[]()``. Instead it requires each ``operator->()`` and ``operator[]()``. Instead it requires each
``iterator_facade`` instantiation to meet the requirements according ``iterator_facade`` instantiation to meet the requirements of its
to its ``iterator_category``. ``iterator_category``.
Iterator Adaptor Iterator Adaptor
================ ================
@@ -542,14 +541,13 @@ Class template ``iterator_facade``
``iterator_facade`` requirements ``iterator_facade`` requirements
-------------------------------- --------------------------------
The ``Derived`` template parameter must be a derived class of The ``Derived`` template parameter must be a class derived from
``iterator_facade``. The rest of the template parameters specify the ``iterator_facade``.
types for the member typedefs in ``iterator_facade``.
The following table describes the requirements on the type deriving The following table describes the requirements on the ``Derived``
from the ``iterator_facade``. The expressions listed in the table are parameter. Depending on the resulting iterator's
required to be valid depending on the category of the derived iterator ``iterator_category``, a subset of the expressions listed in the table
type. are required to be valid .
In the table below, ``X`` is the derived iterator type, ``a`` is an In the table below, ``X`` is the derived iterator type, ``a`` is an
object of type ``X``, ``b`` and ``c`` are objects of type ``const X``, object of type ``X``, ``b`` and ``c`` are objects of type ``const X``,
@@ -717,14 +715,15 @@ interoperable with ``X``.
Iterator adaptor [lib.iterator.adaptor] Iterator adaptor [lib.iterator.adaptor]
======================================= =======================================
The ``iterator_adaptor`` is a base class template which is a derived The ``iterator_adaptor`` is a base class template derived from an
class of ``iterator_facade``. The core interface functions expected by instantiation of ``iterator_facade``. The core interface functions
``iterator_facade`` are implemented in terms of the ``Base`` template expected by ``iterator_facade`` are implemented in terms of the
parameter. A class derived from ``iterator_adaptor`` typically ``iterator_adaptor``\ 's ``Base`` template parameter. A class derived
overrides some of the (non-vertual) core interface functions to adapt from ``iterator_adaptor`` typically implements some of
the behaviour of the iterator. The ``Base`` type need not meet the the (non-virtual) core interface functions to adapt the behaviour of
full requirements for an iterator. It need only support the operations the ``Base`` type. The ``Base`` type need not meet the full
that are not overriden by the users derived class. requirements of an iterator; it need only support the default
operations that are not implemented by the users derived class.
Class template ``iterator_adaptor`` Class template ``iterator_adaptor``
@@ -937,6 +936,8 @@ indirect iterator.
Reverse iterator Reverse iterator
---------------- ----------------
.. I think we'd better strike the old reverse_iterator text from the standard, eh?
The reverse iterator adaptor flips the direction of a base iterator's The reverse iterator adaptor flips the direction of a base iterator's
motion. Invoking ``operator++()`` moves the base iterator backward and motion. Invoking ``operator++()`` moves the base iterator backward and
invoking ``operator--()`` moves the base iterator forward. invoking ``operator--()`` moves the base iterator forward.