Motivation

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

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.

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.

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.

Reference

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.]

&static_cast<Derived const*>(this)->dereference()

static_cast<Derived*>(this)->increment();
return *this;

Derived tmp(static_cast<Derived const*>(this));
++*this;
return tmp;

static_cast<Derived*>(this)->decrement();
return *this;

Derived tmp(static_cast<Derived const*>(this));
--*this;
return tmp;

static_cast<Derived*>(this)->advance(n);
return *this;

static_cast<Derived*>(this)->advance(-n);
return *this;