boostorg/iterator
1
0
Fork 1
mirror of https://github.com/boostorg/iterator.git synced 2025-08-01 05:44:32 +02:00
Code Issues Packages Projects Releases Wiki Activity

Updated pointee and indirect_reference so that pointee represents the

Browse Source 
immutability of the pointed-to type via const qualification.  The
pointee of a proxy-based iterator will be const qualified unless a
mutable reference to the value_type can be bound to the returned
proxy.

Added a test for pointee

Fixed iterator_facade so operator[] result type computation didn't
cause a problem with abstract types.

Updated iterator_facade operator[] docs for accuracy.

Allowed Borland to simply fail the indirect_iterator_member_types test
because of its lame const-dropping, instead of trying to work around
it.


[SVN r21579]
This commit is contained in:
Dave Abrahams
2004-01-11 00:03:09 +00:00
parent dd5fb425fa
commit 6c62f31f0a
7 changed files with 150 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
doc/iterator_facade_body.rst
View File

@@ -151,14 +151,16 @@ into the temporary iterator ``p+n``, which is destroyed when
Writable iterators built with ``iterator_facade`` implement the
semantics required by the preferred resolution to `issue 299`_ and
adopted by proposal n1550_: the result of ``p[n]`` is a proxy object
containing a copy of ``p+n``, and ``p[n] = x`` is equivalent to ``*(p
+ n) = x``. This approach will work properly for any random-access
iterator regardless of the other details of its implementation. A
user who knows more about the implementation of her iterator is free
to implement an ``operator[]`` which returns an lvalue in the derived
iterator class; it will hide the one supplied by ``iterator_facade``
from clients of her iterator.
adopted by proposal n1550_: the result of ``p[n]`` is an object
convertible to the iterator's ``value_type``, and ``p[n] = x`` is
equivalent to ``*(p + n) = x`` (Note: This result object may be
implemented as a proxy containing a copy of ``p+n``). This approach
will work properly for any random-access iterator regardless of the
other details of its implementation. A user who knows more about
the implementation of her iterator is free to implement an
``operator[]`` that returns an lvalue in the derived iterator
class; it will hide the one supplied by ``iterator_facade`` from
clients of her iterator.
.. _n1550: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1550.html