Forward Iterator (1) -> Single Pass Iterator and Readable Iterator +
Forward Iterator (1) -> Single Pass Iterator and Readable Iterator, Forward Iterator (2) -> Forward Traversal Iterator and Readable Iterator
find_first_of@@ -387,7 +196,7 @@ Forward Iterator (2) -> Forward Traversal Iterator and Readable Iterator
Forward Iterator -> Forward Traversal Iterator and Swappable Iterator
rotate-
Forward Iterator (1) -> Swappable Iterator and Single Pass Iterator +
Forward Iterator (1) -> Swappable Iterator and Single Pass Iterator, Forward Iterator (2) -> Swappable Iterator and Incrementable Iterator
swap_ranges@@ -457,30 +266,31 @@ matches with the original input and output iterator requirements.
The relationship between the new iterator concepts and the old are given in the following diagram.
As in the existing library, we provide tags for purposes of -dispatching. There are two hierarchies of tags, one for the access -concepts and one for the traversal concepts. The tags are related via +
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. -There is not a tag for Lvalue Iterator because one can easily deduce -whether an iterator is an Lvalue Iterator by checking whether -iterator_traits<Iterator>::reference is a real reference.
+Since the access concepts are not related via refinment, but instead +cover orthogonal issues, we do not use tags for the access concepts, +but instead use the equivalent of a bitfield.We provide an access mechanism for mapping iterator types to the new -tags. Our design reuses iterator_traits<Iter>::iterator_category -as the access mechanism. To that end, a pair of access and -traversal tags are combined into a single type using the following -iterator_tag class.
+traversal tags and access bitfield. Our design reuses +iterator_traits<Iter>::iterator_category as the access +mechanism. To that end, a pair of access and traversal tags are +combined into a single type using the following iterator_tag class.
-template <class AccessTag, class Reference, class TraversalTag>
-struct iterator_tag : /* appropriate old category or categories */
-{
- typedef AccessTag access;
+enum iterator_access { readable_iterator = 1, writable_iterator = 2,
+ swappable_iterator = 4, lvalue_iterator = 8 };
+
+template <iterator_access x, class TraversalTag>
+struct iterator_tag : /* appropriate old category or categories */ {
+ static const iterator_access access = x;
typedef TraversalTag traversal;
};
The iterator_tag class template is derived from the appropriate iterator tag or tags from the old requirements based on the new-style -tags passed as template parameters. The algorithm for determining the +tags passed as template parameters. The algorithm for determining the old tag or tags from the new 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 @@ -488,15 +298,22 @@ example, a 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 two helper classes that make it convenient to obtain -the access and traversal tags of an iterator. These helper classes -work both for iterators whose iterator_category is +
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 access_category { typedef ... type; };
-template <class Iterator> struct traversal_category { typedef ... type; };
-
+-
+
- :: +
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 @@ -1136,11 +953,5 @@ LocalWords: TraversalTag typename lvalues DWA Hmm JGS -->