diff --git a/doc/facade-and-adaptor.html b/doc/facade-and-adaptor.html index 996ea4c..ca810a4 100755 --- a/doc/facade-and-adaptor.html +++ b/doc/facade-and-adaptor.html @@ -3,204 +3,13 @@
- +Iterators play an important role in modern C++ programming. The iterator is the central abstraction of the algorithms of the Standard Library, allowing algorithms to be re-used in in a wide variety of @@ -400,15 +207,15 @@ applies some user-specified function during the dereference of the iterator.
This proposal is purely an addition to the C++ standard library. However, note that this proposal relies on the proposal for New Iterator Concepts.
This proposal is formulated in terms of the new iterator concepts as proposed in n1477, since user-defined and especially adapted iterators suffer from the well known categorization problems that are @@ -418,7 +225,7 @@ is a direct mapping between new and old categories. This proposal could be reformulated using this mapping if n1477 was not accepted.
The question of iterator interoperability is poorly addressed in the current standard. There are currently two defect reports that are concerned with interoperability issues.
@@ -438,7 +245,7 @@ fixes the issues raised in 280. It provides the desired interoperability without introducing unwanted overloads.While the iterator interface is rich, there is a core subset of the interface that is necessary for all the functionality. We have identified the following core behaviors for iterators:
@@ -457,7 +264,7 @@ include the associated types exposed through iterator traits: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. The proposal does not use policy +objects to specify the behavior. iterator_facade does not use policy objects for several reasons:
@@ -477,7 +284,7 @@ impossible.
The user of iterator_facade derives his iterator class from an instantiation of iterator_facade which takes the derived iterator class as the first template parameter. The order of the other @@ -490,8 +297,8 @@ parameter and omit the Referenceiterator facade -requirements.
+briefly below and in more detail in the iterator facade +requirements.
@@ -539,14 +346,13 @@ constructor. Finally, if the iterator is to model Forward Traversal Iterator or a more-refined iterator concept, a default constructor is required. - -Iterator Core Access
+Iterator Core Access
iterator_facade and the operator implementations need to be able to access the core member functions in the derived class. Making the core member functions public would expose an implementation detail to -the user. This proposal frees the public interface of the derived -iterator type from any implementation detail.
+the user. The design used here ensures that implementation details do +not appear in the public interface of the derived iterator type.Preventing direct access to the core member functions has two advantages. First, there is no possibility for the user to accidently use a member function of the iterator when a member of the value_type @@ -559,12 +365,11 @@ directly.
In a naive implementation, keeping the derived class' core member functions private would require it to grant friendship to iterator_facade and each of the seven operators. In order to -reduce the burden of limiting access, this proposal provides -iterator_core_access, a class that acts as a gateway to the core -member functions in the derived iterator class. The author of the -derived class only needs to grant friendship to -iterator_core_access to make his core member functions available -to the library.
+reduce the burden of limiting access, iterator_core_access is +provided, a class that acts as a gateway to the core member functions +in the derived iterator class. The author of the derived class only +needs to grant friendship to iterator_core_access to make his core +member functions available to the library.iterator_core_access will be typically implemented as an empty @@ -576,13 +381,13 @@ open a safety loophole, as every core member function preserves the invariants of the iterator.
--operator[]
+operator[]
The indexing operator for a generalized iterator presents special challenges. A random access iterator's operator[] is only required to return something convertible to its value_type. Requiring that it return an lvalue would rule out currently-legal random-access iterators which hold the referenced value in a data -member (e.g. counting_iterator), because *(p+n) is a reference +member (e.g. counting_iterator), because *(p+n) is a reference into the temporary iterator p+n, which is destroyed when operator[] returns.
Writable iterators built with iterator_facade implement the @@ -596,8 +401,8 @@ to implement an operator[] whi iterator class; it will hide the one supplied by iterator_facade from clients of her iterator.
-operator->
++operator->
The reference type of a readable iterator (and today's input iterator) need not in fact be a reference, so long as it is convertible to the iterator's value_type. When the value_type @@ -605,14 +410,22 @@ is a class, however, it must still be possible to access members 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->.
-This proposal does not explicitly specify the return type for -operator-> and operator[]. Instead it requires each -iterator_facade instantiation to meet the requirements of its -iterator_category.
+The return type for operator-> and operator[] is not +explicitly specified. Instead it requires each iterator_facade +instantiation to meet the requirements of its iterator_category.
++
++ + + + + [Cop95] [Coplien, 1995] Coplien, J., Curiously Recurring Template +Patterns, C++ Report, February 1995, pp. 24-27. -Iterator Adaptor
-The iterator_adaptor class template adapts some Base 3 +
Iterator Adaptor
+The iterator_adaptor class template adapts some Base 3 type to create a new iterator. Instantiations of iterator_adaptor are derived from a corresponding instantiation of iterator_facade and implement the core behaviors in terms of the Base type. In @@ -621,7 +434,7 @@ instance of the Base type, whi
- [3] The term "Base" here does not refer to a base class and is + @@ -647,7 +460,7 @@ template parameter may not always be identical to the iterator's assumption. [3] The term "Base" here does not refer to a base class and is not meant to imply the use of derivation. We have followed the lead of the standard library, which provides a base() function to access the underlying iterator object of a reverse_iterator adaptor. -Specialized Adaptors
+Specialized Adaptors
This proposal also contains several examples of specialized adaptors which were easily implemented using iterator_adaptor:
@@ -684,9 +497,9 @@ Standard compliant iterators).
-Proposed Text
+Proposed Text
-Header <iterator_helper> synopsis [lib.iterator.helper.synopsis]
+Header <iterator_helper> synopsis [lib.iterator.helper.synopsis]
struct use_default; @@ -747,345 +560,15 @@ class function_output_iterator;-Iterator facade [lib.iterator.facade]
-iterator_facade is a base class template which implements the -interface of standard iterators in terms of a few core functions -and associated types, to be supplied by a derived iterator class.
+Iterator facade [lib.iterator.facade]
+..include:: iterator_facade_abstract.rst
--Class template iterator_facade
--template < - class Derived - , class Value - , class AccessCategory - , class TraversalCategory - , class Reference = /* see below */ - , class Difference = ptrdiff_t -> -class iterator_facade { -public: - typedef remove_cv<Value>::type value_type; - typedef Reference reference; - typedef /* see description of operator-> */ pointer; - typedef Difference difference_type; - typedef iterator_tag<AccessCategory, TraversalCategory> iterator_category; - - reference operator*() const; - /* see below */ operator->() const; - /* see below */ operator[](difference_type n) const; - Derived& operator++(); - Derived operator++(int); - Derived& operator--(); - Derived operator--(int); - Derived& operator+=(difference_type n); - Derived& operator-=(difference_type n); - Derived operator-(difference_type n) const; -}; - -// Comparison operators -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type // exposition -operator ==(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator !=(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator <(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator <=(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator >(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator >=(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator >=(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -// Iterator difference -template <class Dr1, class V1, class AC1, class TC1, class R1, class D1, - class Dr2, class V2, class AC2, class TC2, class R2, class D2> -typename enable_if_interoperable<Dr1, Dr2, bool>::type -operator -(iterator_facade<Dr1, V1, AC1, TC1, R1, D1> const& lhs, - iterator_facade<Dr2, V2, AC2, TC2, R2, D2> const& rhs); - -// Iterator addition -template <class Derived, class V, class AC, class TC, class R, class D> -Derived operator+ (iterator_facade<Derived, V, AC, TC, R, D> const&, - typename Derived::difference_type n) --[Note: The enable_if_interoperable template used above is for exposition -purposes. The member operators should be only be in an overload set -provided the derived types Dr1 and Dr2 are interoperable, by -which we mean they are convertible to each other. The -enable_if_interoperable approach uses SFINAE to take the operators -out of the overload set when the types are not interoperable.]
- ---iterator_facade requirements
-The Derived template parameter must be a class derived from -iterator_facade.
-The default for the Reference parameter is Value& if the -access category for iterator_facade is implicitly convertible to -writable_iterator_tag, and const Value& otherwise.
-The following table describes the other requirements on the -Derived parameter. Depending on the resulting iterator's -iterator_category, a subset of the expressions listed in the table -are required to be valid. The operations in the first column must be -accessible to member functions of class iterator_core_access.
-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, -n is an object of X::difference_type, y is a constant -object of a single pass iterator type interoperable with X, and z -is a constant object of a random access traversal iterator type -interoperable with X.
--
- -- - -- - - - - - - Expression -Return Type -Assertion/Note -Required to implement -Iterator Concept(s) -- c.dereference() -X::reference -- Readable Iterator, Writable -Iterator -- c.equal(b) -convertible to bool -true iff b and c are -equivalent. -Single Pass Iterator -- c.equal(y) -convertible to bool -true iff c and y refer to the -same position. Implements c == y -and c != y. -Single Pass Iterator -- a.advance(n) -unused -- Random Access Traversal -Iterator -- a.increment() -unused -- Incrementable Iterator -- a.decrement() -unused -- Bidirectional Traversal -Iterator -- c.distance_to(b) -convertible to -X::difference_type -equivalent to distance(c, b) -Random Access Traversal -Iterator -- - c.distance_to(z) -convertible to -X::difference_type -equivalent to distance(c, z). -Implements c - z, c < z, c -<= z, c > z, and c >= c. -Random Access Traversal -Iterator --iterator_facade operations
-The operations in this section are described in terms of operations on -the core interface of Derived which may be inaccessible -(i.e. private). The implementation should access these operations -through member functions of class iterator_core_access.
-reference operator*() const;
--
-- - - - - Returns: static_cast<Derived const*>(this)->dereference() -operator->() const; (see below)
--
-- - - - - Returns: - If X::reference is a reference type, returns an object -of type X::pointer equal to:
--&static_cast<Derived const*>(this)->dereference() --Otherwise returns an object of unspecified type such that, given an -object a of type X, a->m is equivalent to (w = *a, -w.m) for some temporary object w of type X::value_type.
-The type X::pointer is Value* if the access category for -X is implicitly convertible to writable_iterator_tag, and -Value const* otherwise.
-unspecified operator[](difference_type n) const;
--
-- - - - - Returns: an object convertible to X::reference and holding a copy -p of a+n such that, for a constant object v of type -X::value_type, X::reference(a[n] = v) is equivalent -to p = v. -Derived& operator++();
--
- -- - - - - Effects: - -static_cast<Derived*>(this)->increment(); -return *this; --Derived operator++(int);
--
-- - - - - Effects: - -Derived tmp(static_cast<Derived const*>(this)); -++*this; -return tmp; --Derived& operator--();
--
-- - - - - Effects: - -static_cast<Derived*>(this)->decrement(); -return *this; --Derived operator--(int);
--
-- - - - - Effects: - -Derived tmp(static_cast<Derived const*>(this)); ---*this; -return tmp; --Derived& operator+=(difference_type n);
--
-- - - - - Effects: - -static_cast<Derived*>(this)->advance(n); -return *this; --Derived& operator-=(difference_type n);
--
-- - - - - Effects: - -static_cast<Derived*>(this)->advance(-n); -return *this; --Derived operator-(difference_type n) const;
--
+- - - - Effects: Derived tmp(static_cast<Derived const*>(this)); -return tmp -= n; -- - Returns: static_cast<Derived const*>(this)->advance(-n); -Class template iterator_facade
+..include:: iterator_facade_ref.rst
-Iterator adaptor [lib.iterator.adaptor]
+Iterator adaptor [lib.iterator.adaptor]
The iterator_adaptor is a base class template derived from an instantiation of iterator_facade. The core interface functions expected by iterator_facade are implemented in terms of the @@ -1097,7 +580,7 @@ depends on the operations supported by the iterator_facade are redefined in the Derived class.
-Class template iterator_adaptor
+Class template iterator_adaptor
template < class Derived @@ -1142,7 +625,7 @@ class iterator_adaptor-iterator_adaptor requirements
+iterator_adaptor requirements
The Derived template parameter must be a derived class of iterator_adaptor. The Base type must implement the expressions involving m_iterator in the specifications of those private member @@ -1196,7 +679,7 @@ else iterator_category = Category; -->
-iterator_adaptor public operations
+iterator_adaptor public operations
iterator_adaptor();
@@ -1230,7 +713,7 @@ else -iterator_adaptor protected member functions
+iterator_adaptor protected member functions
Base const& base_reference() const;
@@ -1251,7 +734,7 @@ else -iterator_adaptor private member functions
+iterator_adaptor private member functions
typename iterator_adaptor::reference dereference() const;
@@ -1320,7 +803,7 @@ typename iterator_adaptor::difference_type distance_to( -Specialized adaptors [lib.iterator.special.adaptors]
+Specialized adaptors [lib.iterator.special.adaptors]
[Note: The enable_if_convertible<X,Y>::type expression used in @@ -1331,7 +814,7 @@ type Y. The -
Indirect iterator
+Indirect iterator
The indirect iterator adapts an iterator by applying an extra dereference inside of operator*(). For example, this iterator adaptor makes it possible to view a container of pointers @@ -1340,7 +823,7 @@ adaptor makes it possible to view a container of pointers
-Class template indirect_iterator
+Class template indirect_iterator
template < class Iterator @@ -1375,7 +858,7 @@ private: // as-if specification-indirect_iterator requirements
+indirect_iterator requirements
The value_type of the Iterator template parameter should itself be dereferenceable. The return type of the operator* for the value_type must be the same type as the Reference template @@ -1400,7 +883,7 @@ iterator will model the most refined standard access concept that is modeled by the value type of Iterator.
-indirect_iterator operations
+indirect_iterator operations
indirect_iterator();
@@ -1448,13 +931,13 @@ indirect_iterator( -Reverse iterator
+Reverse iterator
The reverse iterator adaptor flips the direction of a base iterator's motion. Invoking operator++() moves the base iterator backward and invoking operator--() moves the base iterator forward.
-Class template reverse_iterator
+Class template reverse_iterator
template <class Iterator> class reverse_iterator : @@ -1493,7 +976,7 @@ private: // as-if specification-reverse_iterator requirements
+reverse_iterator requirements
The base Iterator must be a model of Bidirectional Traversal Iterator. The resulting reverse_iterator will be a model of the most refined standard traversal and access concepts that are modeled @@ -1540,14 +1023,14 @@ reverse_iterator(
-Transform iterator
+Transform iterator
The transform iterator adapts an iterator by applying some function object to the result of dereferencing the iterator. In other words, the operator* of the transform iterator first dereferences the base iterator, passes the result of this to the function object, and then returns the result.
-Class template transform_iterator
+Class template transform_iterator
template <class AdaptableUnaryFunction, class Iterator, @@ -1575,7 +1058,7 @@ private:-transform_iterator requirements
+transform_iterator requirements
The type AdaptableUnaryFunction must be Assignable, Copy Constructible, and the expression f(x) must be valid where f is an object of type AdaptableUnaryFunction, x is an object of @@ -1600,7 +1083,7 @@ concept that is modeled by Iterator result_type.
-transform_iterator public operations
+transform_iterator public operations
transform_iterator();
@@ -1649,7 +1132,7 @@ transform_iterator( -transform_iterator private operations
+transform_iterator private operations
typename transform_iterator::value_type dereference() const;
@@ -1662,7 +1145,7 @@ transform_iterator( -Filter iterator
+Filter iterator
The filter iterator adaptor creates a view of an iterator range in which some elements of the range are skipped over. A predicate function object controls which elements are skipped. When the @@ -1674,7 +1157,7 @@ of the underlying range. Therefore the constructor of the filter iterator takes two iterator parameters: the position for the filtered iterator and the end of the range.
-Class template filter_iterator
+Class template filter_iterator
template <class Predicate, class Iterator> class filter_iterator @@ -1716,7 +1199,7 @@ class filter_iterator-filter_iterator requirements
+filter_iterator requirements
The base Iterator parameter must be a model of Readable Iterator and Single Pass Iterator. The resulting filter_iterator will be a model of Forward Traversal Iterator if Iterator is, otherwise the @@ -1732,7 +1215,7 @@ expression p(x) must be valid p(x) must be convertible to bool.
--filter_iterator operations
+filter_iterator operations
filter_iterator();
@@ -1805,14 +1288,14 @@ filter_iterator( --Counting iterator
++Counting iterator
The counting iterator adaptor implements dereference by returning a reference to the base object. The other operations are implemented by the base m_iterator, as per the inheritance from iterator_adaptor.
-Class template counting_iterator
+Class template counting_iterator
template <class Incrementable, class Category = use_default, class Difference = use_default> class counting_iterator @@ -1845,7 +1328,7 @@ the cases when the Incrementable
-counting_iterator requirements
+counting_iterator requirements
The Incrementable type must be Default Constructible, Copy Constructible, and Assignable. The default distance is an implementation defined signed integegral type.
@@ -1873,7 +1356,7 @@ i < j-counting_iterator operations
+counting_iterator operations
counting_iterator();
@@ -1904,7 +1387,7 @@ object copy constructed from x -Function output iterator
+Function output iterator
The function output iterator adaptor makes it easier to create custom output iterators. The adaptor takes a unary function and creates a model of Output Iterator. Each item assigned to the output iterator is @@ -1913,7 +1396,7 @@ iterator is that creating a conforming output iterator is non-trivial, particularly because the proper implementation usually requires a proxy object.
-Class template function_output_iterator
+Class template function_output_iterator
template <class UnaryFunction> class function_output_iterator { @@ -1941,7 +1424,7 @@ public:-function_output_iterator requirements
+function_output_iterator requirements
The UnaryFunction must be Assignable, Copy Constructible, and the expression f(x) must be valid, where f is an object of type UnaryFunction and x is an object of a type accepted by f. @@ -1949,7 +1432,7 @@ The resulting function_output_iterator
-function_output_iterator operations
+function_output_iterator operations
explicit function_output_iterator(const UnaryFunction& f = UnaryFunction());
@@ -1990,7 +1473,7 @@ a copy of the unary function f -function_output_iterator::output_proxy operations
+function_output_iterator::output_proxy operations
output_proxy(UnaryFunction& f);
-
@@ -2014,14 +1497,6 @@ return *this; -
- - - - - [Cop95] [Coplien, 1995] Coplien, J., Curiously Recurring Template -Patterns, C++ Report, February 1995, pp. 24-27.
- diff --git a/doc/facade-and-adaptor.rst b/doc/facade-and-adaptor.rst index 3c71e97..886124c 100644 --- a/doc/facade-and-adaptor.rst +++ b/doc/facade-and-adaptor.rst @@ -164,213 +164,12 @@ interoperability without introducing unwanted overloads. Iterator Facade =============== -While the iterator interface is rich, there is a core subset of the -interface that is necessary for all the functionality. We have -identified the following core behaviors for iterators: - -* dereferencing -* incrementing -* decrementing -* equality comparison -* random-access motion -* distance measurement - -In addition to the behaviors listed above, the core interface elements -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. The proposal does not use policy -objects for several reasons: - - 1. the creation and eventual copying of the policy object may create - overhead that can be avoided with the current approach. - - 2. The policy object approach does not allow for custom constructors - on the created iterator types, an essential feature if - ``iterator_facade`` should be used in other library - 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 - instantiations of ``iterator_facade``. Cumbersome type generator - metafunctions would be needed to build new parameterized - iterators, and a separate ``iterator_adaptor`` layer would be - impossible. - -Usage ------ - -The user of ``iterator_facade`` derives his iterator class from an -instantiation of ``iterator_facade`` which takes the derived iterator -class as the first template parameter. The order of the other -template parameters to ``iterator_facade`` have been carefully chosen -to take advantage of useful defaults. For example, when defining a -constant lvalue iterator, the user can pass a const-qualified version -of the iterator's ``value_type`` as ``iterator_facade``\ 's ``Value`` -parameter and omit the ``Reference`` parameter which follows. - -The derived iterator class must define member functions implementing -the iterator's core behaviors. The following table describes -expressions which are required to be valid depending on the category -of the derived iterator type. These member functions are described -briefly below and in more detail in the `iterator facade -requirements`_. - - +------------------------+-------------------------------+ - |Expression |Effects | - +========================+===============================+ - |``i.dereference()`` |Access the value referred to | - +------------------------+-------------------------------+ - |``i.equal(j)`` |Compare for equality with ``j``| - +------------------------+-------------------------------+ - |``i.increment()`` |Advance by one position | - +------------------------+-------------------------------+ - |``i.decrement()`` |Retreat by one position | - +------------------------+-------------------------------+ - |``i.advance(n)`` |Advance by ``n`` positions | - +------------------------+-------------------------------+ - |``i.distance_to(j)`` |Measure the distance to ``j`` | - +------------------------+-------------------------------+ - -.. Should we add a comment that a zero overhead implementation of iterator_facade - is possible with proper inlining? - -In addition to implementing the core interface functions, an iterator -derived from ``iterator_facade`` typically defines several -constructors. To model any of the standard iterator concepts, the -iterator must at least have a copy constructor. Also, if the iterator -type ``X`` is meant to be automatically interoperate with another -iterator type ``Y`` (as with constant and mutable iterators) then -there must be an implicit conversion from ``X`` to ``Y`` or from ``Y`` -to ``X`` (but not both), typically implemented as a conversion -constructor. Finally, if the iterator is to model Forward Traversal -Iterator or a more-refined iterator concept, a default constructor is -required. - - - -Iterator Core Access -==================== - -``iterator_facade`` and the operator implementations need to be able -to access the core member functions in the derived class. Making the -core member functions public would expose an implementation detail to -the user. This proposal frees the public interface of the derived -iterator type from any implementation detail. - -Preventing direct access to the core member functions has two -advantages. First, there is no possibility for the user to accidently -use a member function of the iterator when a member of the value_type -was intended. This has been an issue with smart pointer -implementations in the past. The second and main advantage is that -library implementers can freely exchange a hand-rolled iterator -implementation for one based on ``iterator_facade`` without fear of -breaking code that was accessing the public core member functions -directly. - -In a naive implementation, keeping the derived class' core member -functions private would require it to grant friendship to -``iterator_facade`` and each of the seven operators. In order to -reduce the burden of limiting access, this proposal provides -``iterator_core_access``, a class that acts as a gateway to the core -member functions in the derived iterator class. The author of the -derived class only needs to grant friendship to -``iterator_core_access`` to make his core member functions available -to the library. - -.. This is no long uptodate -thw -.. Yes it is; I made sure of it! -DWA - -``iterator_core_access`` will be typically implemented as an empty -class containing only private static member functions which invoke the -iterator core member functions. There is, however, no need to -standardize the gateway protocol. Note that even if -``iterator_core_access`` used public member functions it would not -open a safety loophole, as every core member function preserves the -invariants of the iterator. - -``operator[]`` -================ - -The indexing operator for a generalized iterator presents special -challenges. A random access iterator's ``operator[]`` is only -required to return something convertible to its ``value_type``. -Requiring that it return an lvalue would rule out currently-legal -random-access iterators which hold the referenced value in a data -member (e.g. `counting_iterator`_), because ``*(p+n)`` is a reference -into the temporary iterator ``p+n``, which is destroyed when -``operator[]`` returns. - -Writable iterators built with ``iterator_facade`` implement the -semantics required by the preferred resolution to `issue 299`_ and -adopted by proposal `n1477`_: 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. - -.. _issue 299: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299 - -.. _`operator arrow`: - -``operator->`` -============== - -The ``reference`` type of a readable iterator (and today's input -iterator) need not in fact be a reference, so long as it is -convertible to the iterator's ``value_type``. When the ``value_type`` -is a class, however, it must still be possible to access members -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->``. - -This proposal does not explicitly specify the return type for -``operator->`` and ``operator[]``. Instead it requires each -``iterator_facade`` instantiation to meet the requirements of its -``iterator_category``. +.. include:: iterator_facade_body.rst Iterator Adaptor ================ -The ``iterator_adaptor`` class template adapts some ``Base`` [#base]_ -type to create a new iterator. Instantiations of ``iterator_adaptor`` -are derived from a corresponding instantiation of ``iterator_facade`` -and implement the core behaviors in terms of the ``Base`` type. In -essence, ``iterator_adaptor`` merely forwards all operations to an -instance of the ``Base`` type, which it stores as a member. - -.. [#base] The term "Base" here does not refer to a base class and is - not meant to imply the use of derivation. We have followed the lead - of the standard library, which provides a base() function to access - the underlying iterator object of a ``reverse_iterator`` adaptor. - -The user of ``iterator_adaptor`` creates a class derived from an -instantiation of ``iterator_adaptor`` and then selectively -redefines some of the core member functions described in the table -above. The ``Base`` type need not meet the full requirements for an -iterator. It need only support the operations used by the core -interface functions of ``iterator_adaptor`` that have not been -redefined in the user's derived class. - -Several of the template parameters of ``iterator_adaptor`` default to -``use_default``. This allows the user to make use of a default -parameter even when the user wants to specify a parameter later in the -parameter list. Also, the defaults for the corresponding associated -types are fairly complicated, so metaprogramming is required to -compute them, and ``use_default`` can help to simplify the -implementation. Finally, ``use_default`` is not left unspecified -because specification helps to highlight that the ``Reference`` -template parameter may not always be identical to the iterator's -``reference`` type, and will keep users making mistakes based on that -assumption. +.. include:: iterator_adaptor_body.rst Specialized Adaptors ==================== @@ -488,296 +287,12 @@ Header ```` synopsis [lib.iterator.helper.synopsis] Iterator facade [lib.iterator.facade] ===================================== -``iterator_facade`` is a base class template which implements the -interface of standard iterators in terms of a few core functions -and associated types, to be supplied by a derived iterator class. +..include:: iterator_facade_abstract.rst Class template ``iterator_facade`` ---------------------------------- -.. parsed-literal:: - - template < - class Derived - , class Value - , class AccessCategory - , class TraversalCategory - , class Reference = /* see below__ \*/ - , class Difference = ptrdiff_t - > - class iterator_facade { - public: - typedef remove_cv ::type value_type; - typedef Reference reference; - typedef /* see `description of operator->`__ \*/ pointer; - typedef Difference difference_type; - typedef iterator_tag iterator_category; - - reference operator\*() const; - /* see below__ \*/ operator->() const; - /* see below__ \*/ operator[](difference_type n) const; - Derived& operator++(); - Derived operator++(int); - Derived& operator--(); - Derived operator--(int); - Derived& operator+=(difference_type n); - Derived& operator-=(difference_type n); - Derived operator-(difference_type n) const; - }; - - // Comparison operators - template - typename enable_if_interoperable ::type // exposition - operator ==(iterator_facade const& lhs, - iterator_facade const& rhs); - - template - typename enable_if_interoperable ::type - operator !=(iterator_facade const& lhs, - iterator_facade const& rhs); - - template - typename enable_if_interoperable ::type - operator <(iterator_facade const& lhs, - iterator_facade const& rhs); - - template - typename enable_if_interoperable ::type - operator <=(iterator_facade const& lhs, - iterator_facade const& rhs); - - template - typename enable_if_interoperable ::type - operator >(iterator_facade const& lhs, - iterator_facade const& rhs); - - template - typename enable_if_interoperable ::type - operator >=(iterator_facade const& lhs, - iterator_facade const& rhs); - - template - typename enable_if_interoperable ::type - operator >=(iterator_facade const& lhs, - iterator_facade const& rhs); - - // Iterator difference - template - typename enable_if_interoperable ::type - operator -(iterator_facade const& lhs, - iterator_facade const& rhs); - - // Iterator addition - template - Derived operator+ (iterator_facade const&, - typename Derived::difference_type n) - - -__ `iterator facade requirements`_ - -__ `operator arrow`_ - -__ `operator arrow`_ - -__ brackets_ - -[*Note:* The ``enable_if_interoperable`` template used above is for exposition -purposes. The member operators should be only be in an overload set -provided the derived types ``Dr1`` and ``Dr2`` are interoperable, by -which we mean they are convertible to each other. The -``enable_if_interoperable`` approach uses SFINAE to take the operators -out of the overload set when the types are not interoperable.] - - -.. we need a new label here because the presence of markup in the - title prevents an automatic link from being generated - -.. _iterator facade requirements: - -``iterator_facade`` requirements --------------------------------- - -The ``Derived`` template parameter must be a class derived from -``iterator_facade``. - -The default for the ``Reference`` parameter is ``Value&`` if the -access category for ``iterator_facade`` is implicitly convertible to -``writable_iterator_tag``, and ``const Value&`` otherwise. - -The following table describes the other requirements on the -``Derived`` parameter. Depending on the resulting iterator's -``iterator_category``, a subset of the expressions listed in the table -are required to be valid. The operations in the first column must be -accessible to member functions of class ``iterator_core_access``. - -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``, -``n`` is an object of ``X::difference_type``, ``y`` is a constant -object of a single pass iterator type interoperable with X, and ``z`` -is a constant object of a random access traversal iterator type -interoperable with ``X``. - -+--------------------+-------------------+-------------------------------------+---------------------------+ -|Expression |Return Type |Assertion/Note |Required to implement | -| | | |Iterator Concept(s) | -+====================+===================+=====================================+===========================+ -|``c.dereference()`` |``X::reference`` | |Readable Iterator, Writable| -| | | |Iterator | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``c.equal(b)`` |convertible to bool|true iff ``b`` and ``c`` are |Single Pass Iterator | -| | |equivalent. | | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``c.equal(y)`` |convertible to bool|true iff ``c`` and ``y`` refer to the|Single Pass Iterator | -| | |same position. Implements ``c == y``| | -| | |and ``c != y``. | | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``a.advance(n)`` |unused | |Random Access Traversal | -| | | |Iterator | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``a.increment()`` |unused | |Incrementable Iterator | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``a.decrement()`` |unused | |Bidirectional Traversal | -| | | |Iterator | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``c.distance_to(b)``|convertible to |equivalent to ``distance(c, b)`` |Random Access Traversal | -| |X::difference_type | |Iterator | -+--------------------+-------------------+-------------------------------------+---------------------------+ -|``c.distance_to(z)``|convertible to |equivalent to ``distance(c, z)``. |Random Access Traversal | -| |X::difference_type |Implements ``c - z``, ``c < z``, ``c |Iterator | -| | |<= z``, ``c > z``, and ``c >= c``. | | -+--------------------+-------------------+-------------------------------------+---------------------------+ - -.. We should explain more about how the - functions in the interface of iterator_facade - are there conditionally. -JGS - - -``iterator_facade`` operations ------------------------------- - -The operations in this section are described in terms of operations on -the core interface of ``Derived`` which may be inaccessible -(i.e. private). The implementation should access these operations -through member functions of class ``iterator_core_access``. - -``reference operator*() const;`` - -:Returns: ``static_cast (this)->dereference()`` - -``operator->() const;`` (see below__) - -__ `operator arrow`_ - -:Returns: If ``X::reference`` is a reference type, returns an object - of type ``X::pointer`` equal to:: - - &static_cast (this)->dereference() - - Otherwise returns an object of unspecified type such that, given an - object ``a`` of type ``X``, ``a->m`` is equivalent to ``(w = *a, - w.m)`` for some temporary object ``w`` of type ``X::value_type``. - - The type ``X::pointer`` is ``Value*`` if the access category for - ``X`` is implicitly convertible to ``writable_iterator_tag``, and - ``Value const*`` otherwise. - - -.. _brackets: - -*unspecified* ``operator[](difference_type n) const;`` - -:Returns: an object convertible to ``X::reference`` and holding a copy - *p* of ``a+n`` such that, for a constant object ``v`` of type - ``X::value_type``, ``X::reference(a[n] = v)`` is equivalent - to ``p = v``. - - - -``Derived& operator++();`` - -:Effects: - - :: - - static_cast (this)->increment(); - return *this; - -.. I realize that the committee is moving away from specifying things - like this in terms of code, but I worried about the imprecision of - saying that a core interface function is invoked without describing - the downcast. An alternative to what I did would be to mention it - above where we talk about accessibility. - - -``Derived operator++(int);`` - -:Effects: - - :: - - Derived tmp(static_cast (this)); - ++*this; - return tmp; - - -``Derived& operator--();`` - -:Effects: - - :: - - static_cast (this)->decrement(); - return *this; - - -``Derived operator--(int);`` - -:Effects: - - :: - - Derived tmp(static_cast (this)); - --*this; - return tmp; - - -``Derived& operator+=(difference_type n);`` - -:Effects: - - :: - - static_cast (this)->advance(n); - return *this; - - -``Derived& operator-=(difference_type n);`` - -:Effects: - - :: - - static_cast (this)->advance(-n); - return *this; - - -``Derived operator-(difference_type n) const;`` - -:Effects: - - Derived tmp(static_cast (this)); - return tmp -= n; - -:Returns: ``static_cast (this)->advance(-n);`` - +..include:: iterator_facade_ref.rst Iterator adaptor [lib.iterator.adaptor] ======================================= @@ -1618,9 +1133,6 @@ and Incrementable Iterator concepts. -.. [Cop95] [Coplien, 1995] Coplien, J., Curiously Recurring Template - Patterns, C++ Report, February 1995, pp. 24-27. - .. LocalWords: Abrahams Siek Witt istream ostream iter MTL strided interoperate LocalWords: CRTP metafunctions inlining lvalue JGS incrementable BGL LEDA cv diff --git a/doc/index.html b/doc/index.html index 7d3058b..b8344c8 100755 --- a/doc/index.html +++ b/doc/index.html @@ -3,13 +3,13 @@ - - The Boost Iterator Library - + +The Boost Iterator Library Boost +-The Boost Iterator Library
+The Boost Iterator Library
@@ -33,10 +33,12 @@ Railway Operation and Construction - Abstract: The Boost Iterator Library is a system of concepts which -extend the C++ standard iterator definition and a framework + Abstract: The Boost Iterator Library contains two parts. The first +is a system of concepts which extend the C++ standard +iterator requirements. The second is a framework of components for building iterators based on these -extended concepts. The extended iterator concepts have +extended concepts and includes several useful iterator +adaptors. The extended iterator concepts have been carefully designed so that new-style iterators will be compatible with old-style algorithms, though algorithms may need to be updated if they want to take full advantage of @@ -175,11 +177,5 @@ LocalWords: incrementable xxx min prev inplace png oldeqnew AccessTag struct LocalWords: TraversalTag typename lvalues DWA Hmm JGS --> -
- diff --git a/doc/index.rst b/doc/index.rst index c8ea881..d8961a4 100755 --- a/doc/index.rst +++ b/doc/index.rst @@ -3,7 +3,7 @@ +++++++++++++++++++++++++++++++++++++++++++++++++ .. |(logo)| image:: ../../../c++boost.gif - :alt: + :alt: Boost __ ../../../index.htm @@ -23,10 +23,12 @@ __ ../../../index.htm .. _`Open Systems Lab`: http://www.osl.iu.edu .. _`Institute for Transport Railway Operation and Construction`: http://www.ive.uni-hannover.de -:Abstract: The Boost Iterator Library is a system of concepts_ which - extend the C++ standard iterator definition and a framework +:Abstract: The Boost Iterator Library contains two parts. The first + is a system of concepts_ which extend the C++ standard + iterator requirements. The second is a framework of components for building iterators based on these - extended concepts. The extended iterator concepts have + extended concepts and includes several useful iterator + adaptors. The extended iterator concepts have been carefully designed so that new-style iterators will be compatible with old-style algorithms, though algorithms may need to be updated if they want to take full advantage of diff --git a/doc/iterator_adaptor.rst b/doc/iterator_adaptor.rst new file mode 100644 index 0000000..0c7dd68 --- /dev/null +++ b/doc/iterator_adaptor.rst @@ -0,0 +1,18 @@ ++++++++++++++++++ + Iterator Adaptor ++++++++++++++++++ + +:Author: David Abrahams, Jeremy Siek, Thomas Witt +:Contact: dave@boost-consulting.com, jsiek@osl.iu.edu, witt@ive.uni-hannover.de +:organization: `Boost Consulting`_, Indiana University `Open Systems + Lab`_, University of Hanover `Institute for Transport + Railway Operation and Construction`_ +:date: $Date$ +:copyright: Copyright Dave Abrahams, Jeremy Siek, and Thomas Witt 2003. All rights reserved + +.. _`Boost Consulting`: http://www.boost-consulting.com +.. _`Open Systems Lab`: http://www.osl.iu.edu +.. _`Institute for Transport Railway Operation and Construction`: http://www.ive.uni-hannover.de + +.. include:: iterator_adaptor_body.rst + diff --git a/doc/iterator_adaptor_body.rst b/doc/iterator_adaptor_body.rst new file mode 100644 index 0000000..0136ad1 --- /dev/null +++ b/doc/iterator_adaptor_body.rst @@ -0,0 +1,32 @@ +The ``iterator_adaptor`` class template adapts some ``Base`` [#base]_ +type to create a new iterator. Instantiations of ``iterator_adaptor`` +are derived from a corresponding instantiation of ``iterator_facade`` +and implement the core behaviors in terms of the ``Base`` type. In +essence, ``iterator_adaptor`` merely forwards all operations to an +instance of the ``Base`` type, which it stores as a member. + +.. [#base] The term "Base" here does not refer to a base class and is + not meant to imply the use of derivation. We have followed the lead + of the standard library, which provides a base() function to access + the underlying iterator object of a ``reverse_iterator`` adaptor. + +The user of ``iterator_adaptor`` creates a class derived from an +instantiation of ``iterator_adaptor`` and then selectively +redefines some of the core member functions described in the table +above. The ``Base`` type need not meet the full requirements for an +iterator. It need only support the operations used by the core +interface functions of ``iterator_adaptor`` that have not been +redefined in the user's derived class. + +Several of the template parameters of ``iterator_adaptor`` default to +``use_default``. This allows the user to make use of a default +parameter even when the user wants to specify a parameter later in the +parameter list. Also, the defaults for the corresponding associated +types are fairly complicated, so metaprogramming is required to +compute them, and ``use_default`` can help to simplify the +implementation. Finally, ``use_default`` is not left unspecified +because specification helps to highlight that the ``Reference`` +template parameter may not always be identical to the iterator's +``reference`` type, and will keep users making mistakes based on that +assumption. + diff --git a/doc/iterator_facade.rst b/doc/iterator_facade.rst new file mode 100644 index 0000000..379e942 --- /dev/null +++ b/doc/iterator_facade.rst @@ -0,0 +1,33 @@ +++++++++++++++++ + Iterator Facade +++++++++++++++++ + +:Author: David Abrahams, Jeremy Siek, Thomas Witt +:Contact: dave@boost-consulting.com, jsiek@osl.iu.edu, witt@ive.uni-hannover.de +:organization: `Boost Consulting`_, Indiana University `Open Systems + Lab`_, University of Hanover `Institute for Transport + Railway Operation and Construction`_ +:date: $Date$ +:copyright: Copyright Dave Abrahams, Jeremy Siek, and Thomas Witt 2003. All rights reserved + +.. _`Boost Consulting`: http://www.boost-consulting.com +.. _`Open Systems Lab`: http://www.osl.iu.edu +.. _`Institute for Transport Railway Operation and Construction`: http://www.ive.uni-hannover.de + +:abstract: + +.. include:: iterator_facade_abstract.rst + +.. contents:: Table of Contents + + +Motivation +---------- + +.. include:: iterator_facade_body.rst + + +Reference +--------- + +.. include:: iterator_facade_ref.rst diff --git a/doc/iterator_facade_abstract.rst b/doc/iterator_facade_abstract.rst new file mode 100644 index 0000000..70c64cb --- /dev/null +++ b/doc/iterator_facade_abstract.rst @@ -0,0 +1,4 @@ +``iterator_facade`` is a base class template which implements the +interface of standard iterators in terms of a few core functions +and associated types, to be supplied by a derived iterator class. + diff --git a/doc/iterator_facade_body.rst b/doc/iterator_facade_body.rst new file mode 100644 index 0000000..ee6fb9c --- /dev/null +++ b/doc/iterator_facade_body.rst @@ -0,0 +1,180 @@ +While the iterator interface is rich, there is a core subset of the +interface that is necessary for all the functionality. We have +identified the following core behaviors for iterators: + +* dereferencing +* incrementing +* decrementing +* equality comparison +* random-access motion +* distance measurement + +In addition to the behaviors listed above, the core interface elements +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: + + 1. the creation and eventual copying of the policy object may create + overhead that can be avoided with the current approach. + + 2. The policy object approach does not allow for custom constructors + on the created iterator types, an essential feature if + ``iterator_facade`` should be used in other library + 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 + instantiations of ``iterator_facade``. Cumbersome type generator + metafunctions would be needed to build new parameterized + iterators, and a separate ``iterator_adaptor`` layer would be + impossible. + +Usage +----- + +The user of ``iterator_facade`` derives his iterator class from an +instantiation of ``iterator_facade`` which takes the derived iterator +class as the first template parameter. The order of the other +template parameters to ``iterator_facade`` have been carefully chosen +to take advantage of useful defaults. For example, when defining a +constant lvalue iterator, the user can pass a const-qualified version +of the iterator's ``value_type`` as ``iterator_facade``\ 's ``Value`` +parameter and omit the ``Reference`` parameter which follows. + +The derived iterator class must define member functions implementing +the iterator's core behaviors. The following table describes +expressions which are required to be valid depending on the category +of the derived iterator type. These member functions are described +briefly below and in more detail in the iterator facade +requirements. + + +------------------------+-------------------------------+ + |Expression |Effects | + +========================+===============================+ + |``i.dereference()`` |Access the value referred to | + +------------------------+-------------------------------+ + |``i.equal(j)`` |Compare for equality with ``j``| + +------------------------+-------------------------------+ + |``i.increment()`` |Advance by one position | + +------------------------+-------------------------------+ + |``i.decrement()`` |Retreat by one position | + +------------------------+-------------------------------+ + |``i.advance(n)`` |Advance by ``n`` positions | + +------------------------+-------------------------------+ + |``i.distance_to(j)`` |Measure the distance to ``j`` | + +------------------------+-------------------------------+ + +.. Should we add a comment that a zero overhead implementation of iterator_facade + is possible with proper inlining? + +In addition to implementing the core interface functions, an iterator +derived from ``iterator_facade`` typically defines several +constructors. To model any of the standard iterator concepts, the +iterator must at least have a copy constructor. Also, if the iterator +type ``X`` is meant to be automatically interoperate with another +iterator type ``Y`` (as with constant and mutable iterators) then +there must be an implicit conversion from ``X`` to ``Y`` or from ``Y`` +to ``X`` (but not both), typically implemented as a conversion +constructor. Finally, if the iterator is to model Forward Traversal +Iterator or a more-refined iterator concept, a default constructor is +required. + + + +Iterator Core Access +-------------------- + +``iterator_facade`` and the operator implementations need to be able +to access the core member functions in the derived class. Making the +core member functions public would expose an implementation detail to +the user. The design used here ensures that implementation details do +not appear in the public interface of the derived iterator type. + +Preventing direct access to the core member functions has two +advantages. First, there is no possibility for the user to accidently +use a member function of the iterator when a member of the value_type +was intended. This has been an issue with smart pointer +implementations in the past. The second and main advantage is that +library implementers can freely exchange a hand-rolled iterator +implementation for one based on ``iterator_facade`` without fear of +breaking code that was accessing the public core member functions +directly. + +In a naive implementation, keeping the derived class' core member +functions private would require it to grant friendship to +``iterator_facade`` and each of the seven operators. In order to +reduce the burden of limiting access, ``iterator_core_access`` is +provided, a class that acts as a gateway to the core member functions +in the derived iterator class. The author of the derived class only +needs to grant friendship to ``iterator_core_access`` to make his core +member functions available to the library. + +.. This is no long uptodate -thw +.. Yes it is; I made sure of it! -DWA + +``iterator_core_access`` will be typically implemented as an empty +class containing only private static member functions which invoke the +iterator core member functions. There is, however, no need to +standardize the gateway protocol. Note that even if +``iterator_core_access`` used public member functions it would not +open a safety loophole, as every core member function preserves the +invariants of the iterator. + +``operator[]`` +-------------- + +The indexing operator for a generalized iterator presents special +challenges. A random access iterator's ``operator[]`` is only +required to return something convertible to its ``value_type``. +Requiring that it return an lvalue would rule out currently-legal +random-access iterators which hold the referenced value in a data +member (e.g. `counting_iterator`__), because ``*(p+n)`` is a reference +into the temporary iterator ``p+n``, which is destroyed when +``operator[]`` returns. + +__ counting_iterator.html + +Writable iterators built with ``iterator_facade`` implement the +semantics required by the preferred resolution to `issue 299`_ and +adopted by proposal `n1477`_: 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. + +.. _`n1477`: http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2003/n1477.html + +.. _issue 299: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#299 + +.. _`operator arrow`: + + +``operator->`` +-------------- + +The ``reference`` type of a readable iterator (and today's input +iterator) need not in fact be a reference, so long as it is +convertible to the iterator's ``value_type``. When the ``value_type`` +is a class, however, it must still be possible to access members +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`` +instantiation to meet the requirements of its ``iterator_category``. + + +.. [Cop95] [Coplien, 1995] Coplien, J., Curiously Recurring Template + Patterns, C++ Report, February 1995, pp. 24-27. + diff --git a/doc/iterator_facade_ref.rst b/doc/iterator_facade_ref.rst new file mode 100644 index 0000000..9a1a344 --- /dev/null +++ b/doc/iterator_facade_ref.rst @@ -0,0 +1,284 @@ +.. parsed-literal:: + + template < + class Derived + , class Value + , class AccessCategory + , class TraversalCategory + , class Reference = /* see below__ \*/ + , class Difference = ptrdiff_t + > + class iterator_facade { + public: + typedef remove_cv::type value_type; + typedef Reference reference; + typedef /* see `description of operator->`__ \*/ pointer; + typedef Difference difference_type; + typedef iterator_tag iterator_category; + + reference operator\*() const; + /* see below__ \*/ operator->() const; + /* see below__ \*/ operator[](difference_type n) const; + Derived& operator++(); + Derived operator++(int); + Derived& operator--(); + Derived operator--(int); + Derived& operator+=(difference_type n); + Derived& operator-=(difference_type n); + Derived operator-(difference_type n) const; + }; + + // Comparison operators + template + typename enable_if_interoperable ::type // exposition + operator ==(iterator_facade const& lhs, + iterator_facade const& rhs); + + template + typename enable_if_interoperable ::type + operator !=(iterator_facade const& lhs, + iterator_facade const& rhs); + + template + typename enable_if_interoperable ::type + operator <(iterator_facade const& lhs, + iterator_facade const& rhs); + + template + typename enable_if_interoperable ::type + operator <=(iterator_facade const& lhs, + iterator_facade const& rhs); + + template + typename enable_if_interoperable ::type + operator >(iterator_facade const& lhs, + iterator_facade const& rhs); + + template + typename enable_if_interoperable ::type + operator >=(iterator_facade const& lhs, + iterator_facade const& rhs); + + template + typename enable_if_interoperable ::type + operator >=(iterator_facade const& lhs, + iterator_facade const& rhs); + + // Iterator difference + template + typename enable_if_interoperable ::type + operator -(iterator_facade const& lhs, + iterator_facade const& rhs); + + // Iterator addition + template + Derived operator+ (iterator_facade const&, + typename Derived::difference_type n) + + +__ `iterator facade requirements`_ + +__ `operator arrow`_ + +__ `operator arrow`_ + +__ brackets_ + +[*Note:* The ``enable_if_interoperable`` template used above is for exposition +purposes. The member operators should be only be in an overload set +provided the derived types ``Dr1`` and ``Dr2`` are interoperable, by +which we mean they are convertible to each other. The +``enable_if_interoperable`` approach uses SFINAE to take the operators +out of the overload set when the types are not interoperable.] + + +.. we need a new label here because the presence of markup in the + title prevents an automatic link from being generated + +.. _iterator facade requirements: + +``iterator_facade`` requirements +================================ + +The ``Derived`` template parameter must be a class derived from +``iterator_facade``. + +The default for the ``Reference`` parameter is ``Value&`` if the +access category for ``iterator_facade`` is implicitly convertible to +``writable_iterator_tag``, and ``const Value&`` otherwise. + +The following table describes the other requirements on the +``Derived`` parameter. Depending on the resulting iterator's +``iterator_category``, a subset of the expressions listed in the table +are required to be valid. The operations in the first column must be +accessible to member functions of class ``iterator_core_access``. + +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``, +``n`` is an object of ``X::difference_type``, ``y`` is a constant +object of a single pass iterator type interoperable with X, and ``z`` +is a constant object of a random access traversal iterator type +interoperable with ``X``. + ++--------------------+-------------------+-------------------------------------+---------------------------+ +|Expression |Return Type |Assertion/Note |Required to implement | +| | | |Iterator Concept(s) | ++====================+===================+=====================================+===========================+ +|``c.dereference()`` |``X::reference`` | |Readable Iterator, Writable| +| | | |Iterator | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``c.equal(b)`` |convertible to bool|true iff ``b`` and ``c`` are |Single Pass Iterator | +| | |equivalent. | | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``c.equal(y)`` |convertible to bool|true iff ``c`` and ``y`` refer to the|Single Pass Iterator | +| | |same position. Implements ``c == y``| | +| | |and ``c != y``. | | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``a.advance(n)`` |unused | |Random Access Traversal | +| | | |Iterator | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``a.increment()`` |unused | |Incrementable Iterator | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``a.decrement()`` |unused | |Bidirectional Traversal | +| | | |Iterator | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``c.distance_to(b)``|convertible to |equivalent to ``distance(c, b)`` |Random Access Traversal | +| |X::difference_type | |Iterator | ++--------------------+-------------------+-------------------------------------+---------------------------+ +|``c.distance_to(z)``|convertible to |equivalent to ``distance(c, z)``. |Random Access Traversal | +| |X::difference_type |Implements ``c - z``, ``c < z``, ``c |Iterator | +| | |<= z``, ``c > z``, and ``c >= c``. | | ++--------------------+-------------------+-------------------------------------+---------------------------+ + +.. We should explain more about how the + functions in the interface of iterator_facade + are there conditionally. -JGS + + +``iterator_facade`` operations +============================== + +The operations in this section are described in terms of operations on +the core interface of ``Derived`` which may be inaccessible +(i.e. private). The implementation should access these operations +through member functions of class ``iterator_core_access``. + +``reference operator*() const;`` + +:Returns: ``static_cast (this)->dereference()`` + +``operator->() const;`` (see below__) + +__ `operator arrow`_ + +:Returns: If ``X::reference`` is a reference type, returns an object + of type ``X::pointer`` equal to:: + + &static_cast (this)->dereference() + + Otherwise returns an object of unspecified type such that, given an + object ``a`` of type ``X``, ``a->m`` is equivalent to ``(w = *a, + w.m)`` for some temporary object ``w`` of type ``X::value_type``. + + The type ``X::pointer`` is ``Value*`` if the access category for + ``X`` is implicitly convertible to ``writable_iterator_tag``, and + ``Value const*`` otherwise. + + +.. _brackets: + +*unspecified* ``operator[](difference_type n) const;`` + +:Returns: an object convertible to ``X::reference`` and holding a copy + *p* of ``a+n`` such that, for a constant object ``v`` of type + ``X::value_type``, ``X::reference(a[n] = v)`` is equivalent + to ``p = v``. + + + +``Derived& operator++();`` + +:Effects: + + :: + + static_cast (this)->increment(); + return *this; + +.. I realize that the committee is moving away from specifying things + like this in terms of code, but I worried about the imprecision of + saying that a core interface function is invoked without describing + the downcast. An alternative to what I did would be to mention it + above where we talk about accessibility. + + +``Derived operator++(int);`` + +:Effects: + + :: + + Derived tmp(static_cast (this)); + ++*this; + return tmp; + + +``Derived& operator--();`` + +:Effects: + + :: + + static_cast (this)->decrement(); + return *this; + + +``Derived operator--(int);`` + +:Effects: + + :: + + Derived tmp(static_cast (this)); + --*this; + return tmp; + + +``Derived& operator+=(difference_type n);`` + +:Effects: + + :: + + static_cast (this)->advance(n); + return *this; + + +``Derived& operator-=(difference_type n);`` + +:Effects: + + :: + + static_cast (this)->advance(-n); + return *this; + + +``Derived operator-(difference_type n) const;`` + +:Effects: + + Derived tmp(static_cast (this)); + return tmp -= n; + +:Returns: ``static_cast (this)->advance(-n);`` + + diff --git a/doc/new-iter-concepts.html b/doc/new-iter-concepts.html index 765a733..d245d04 100755 --- a/doc/new-iter-concepts.html +++ b/doc/new-iter-concepts.html @@ -3,204 +3,13 @@ - + New Iterator Concepts - + - +@@ -216,7 +25,7 @@ ul.auto-toc {Organization: Boost Consulting, Indiana University Open Systems Lab, University of Hanover Institute for Transport Railway Operation and Construction + Date: -2003-07-12 2003-07-13 Number: This document is a revised version of the official N1477=03-0060 Copyright: @@ -1123,11 +932,5 @@ LocalWords: TraversalTag typename lvalues DWA Hmm JGS --> -
-