-
-
The new iterator concepts are backward-compatible with the old
-iterator requirements, and old iterators are forward-compatible with
-the new iterator concepts. That is to say, iterators that satisfy the
-old requirements also satisfy appropriate concepts in the new system,
-and iterators modeling the new concepts will automatically satisfy the
-appropriate old requirements.
+
This proposal for TR1 is a pure extension. Further, the new iterator
+concepts are backward-compatible with the old iterator requirements,
+and old iterators are forward-compatible with the new iterator
+concepts. That is to say, iterators that satisfy the old requirements
+also satisfy appropriate concepts in the new system, and iterators
+modeling the new concepts will automatically satisfy the appropriate
+old requirements.
@@ -382,23 +189,22 @@ made it). -DWA -->
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
-concepts because the new concepts provide a more accurate way to
-express their type requirements. The result is algorithms that are
-usable in more situations and have fewer type requirements.
Note that as currently specified, istreambuf_iterator doesn't
meet the Readable Iterator requirements because its value_type
is not convertible to its reference type. We believe this to
be a defect in the standard; it should be fixed by changing its
reference type from value_type& to value_type const&.
-
-
+
The extensions in this paper suggest several changes we might make
to the working paper for the next standard. These changes are not
a formal part of this proposal for TR1.
-
+
+
The algorithms in the standard library could benefit from the new
+iterator concepts because the new concepts provide a more accurate way
+to express their type requirements. The result is algorithms that are
+usable in more situations and have fewer type requirements.
For the next working paper (but not for TR1), the committee should
consider the following changes to the type requirements of
algorithms. These changes are phrased as phrased as textual
@@ -460,14 +266,14 @@ Bidirectional Iterator (2) -> Bidirectional Traversal Iterator and Writable I
-
+
For the next working paper (but not for TR1), the committee should
consider deprecating the old iterator tags, and
std::iterator_traits, since it will be superceded by individual
traits metafunctions.
-
+
For the next working paper (but not for TR1), the committee should
consider reclassifying vector<bool>::iterator as a Random
Access Traversal Iterator and Readable Iterator and Writable
@@ -476,7 +282,7 @@ Iterator.
-
+
The iterator requirements are to be separated into two groups. One set
of concepts handles the syntax and semantics of value access:
@@ -511,64 +317,19 @@ given in the following diagram.
Like the old iterator requirements, we provide tags for purposes of
dispatching based on the traversal concepts. The tags are related via
inheritance so that a tag is convertible to another tag if the concept
-associated with the first tag is a refinement of the second tag.
-Since the access concepts are not related via refinement, but instead
-cover orthogonal issues, we do not use tags for the access concepts,
-but instead use the equivalent of a bit field.
-We provide an access mechanism for mapping iterator types to the new
-traversal tags and access bit field. Our design reuses
-iterator_traits<Iter>::iterator_category as the access
-mechanism. To that end, the access and traversal information is
-bundled into a single type using the following iterator_tag class.
-
-enum iterator_access { readable_iterator = 1, writable_iterator = 2,
- swappable_iterator = 4, lvalue_iterator = 8 };
-
-template <unsigned int access_bits, class TraversalTag>
-struct iterator_tag : /* appropriate old category or categories */ {
- static const iterator_access access =
- (iterator_access)access_bits &
- (readable_iterator | writable_iterator | swappable_iterator);
- typedef TraversalTag traversal;
-};
-
-
The access_bits argument is declared to be unsigned int
-instead of the enum iterator_access for convenience of use. For
-example, the expression (readable_iterator | writable_iterator)
-produces an unsigned int, not an iterator_access. The purpose of
-the lvalue_iterator part of the iterator_access enum is to
-communicate to iterator_tag whether the reference type is an
-lvalue so that the appropriate old category can be chosen for the base
-class. The lvalue_iterator bit is not recorded in the
-iterator_tag::access data member.
-
The iterator_tag class template is derived from the appropriate
-iterator tag or tags from the old requirements based on the access
-bits and traversal tag passed as template parameters. The algorithm
-for determining the old tag or tags picks the least-refined old
-concepts that include all of the requirements of the access and
-traversal concepts (that is, the closest fit), if any such category
-exists. For example, the category tag for a Readable Single Pass
-Iterator will always be derived from input_iterator_tag, while the
-category tag for a Single Pass Iterator that is both Readable and
-Writable will be derived from both input_iterator_tag and
-output_iterator_tag.
-
We also provide several helper classes that make it convenient to
-obtain the access and traversal characteristics of an iterator. These
-helper classes work both for iterators whose iterator_category is
-iterator_tag and also for iterators using the original iterator
-categories.
-
-template <class Iterator> struct is_readable { typedef ... type; };
-template <class Iterator> struct is_writable { typedef ... type; };
-template <class Iterator> struct is_swappable { typedef ... type; };
-template <class Iterator> struct traversal_category { typedef ... type; };
-
-
We do not include a helper class is_lvalue_iterator because that
-can easily be deduced by checking whether
-iterator_traits<Iterator>::reference is a real reference.
-
The most difficult design decision concerned the operator[]. The
-direct approach for specifying operator[] would have a return type
-of reference; the same as operator*. However, going in this
+associated with the first tag is a refinement of the second tag. Our
+design reuses iterator_traits<Iter>::iterator_category as the
+access mechanism for the traversal tag. If an iterator wishes to meet
+the requirements of both a new iterator concept and an old iterator
+concept, it can use an iterator category type that inherits from both
+the the old iterator tag and the new traversal tag.
+
We do not provide tags for the purposes of dispatching based on the
+access concepts. There are two reasons: we could not find a way to
+automatically infer the right access tags for old-style iterators and
+the need for dispatching based on the access concepts is not as great.
+
A difficult design decision concerned the operator[]. The direct
+approach for specifying operator[] would have a return type of
+reference; the same as operator*. However, going in this
direction would mean that an iterator satisfying the old Random Access
Iterator requirements would not necessarily be a model of Readable or
Writable Lvalue Iterator. Instead we have chosen a design that
@@ -578,23 +339,23 @@ only required to return something convertible to the i[n] = t (for a Writable Iterator).