You probably didn't think of it this way, but the node_base*
-object which underlies node_iterator is itself an iterator,
+object that underlies node_iterator is itself an iterator,
just like all other pointers. If we examine that pointer closely
from an iterator perspective, we can see that it has much in common
with the node_iterator we're building. First, they share most
@@ -358,9 +359,10 @@ of the same associated types (value_typeoperator* and operator== on
the node_iterator return the result of invoking the same
operations on the underlying pointer, via the node_iterator's
-dereference and equal member functions). However, the operator++ for
-node_iterator behaves differently than for node_base*
-since it follows the m_next pointer.
+dereference and equal member functions). The only real behavioral difference
+between node_base* and node_iterator can be observed when
+they are incremented: node_iterator follows the
+m_next pointer, while node_base* just applies an address offset.
It turns out that the pattern of building an iterator on another
iterator-like type (the Base1 type) while modifying
just a few aspects of the underlying type's behavior is an
@@ -384,16 +386,12 @@ class node_iter
private:
struct enabler {}; // a private type avoids misuse
- typedef boost::iterator_adaptor<
- node_iter<Value>, Value*, boost::use_default, boost::forward_traversal_tag
- > super_t;
-
public:
node_iter()
- : super_t(0) {}
+ : node_iter::iterator_adaptor_(0) {}
explicit node_iter(Value* p)
- : super_t(p) {}
+ : node_iter::iterator_adaptor_(p) {}
template <class OtherValue>
node_iter(
@@ -403,14 +401,20 @@ class node_iter
, enabler
>::type = enabler()
)
- : super_t(other.base()) {}
+ : node_iter::iterator_adaptor_(other.base()) {}
private:
friend class boost::iterator_core_access;
void increment() { this->base_reference() = this->base()->next(); }
};
-
You can see an example program which exercises this version of the
+
Note the use of node_iter::iterator_adaptor_ here: because
+iterator_adaptor defines a nested iterator_adaptor_ type
+that refers to itself, that gives us a convenient way to refer to
+the complicated base class type of node_iter<Value>. [Note:
+this technique is known not to work with Borland C++ 5.6.4 and
+Metrowerks CodeWarrior versions prior to 9.0]
+
You can see an example program that exercises this version of the
node iterators here.
In the case of node_iter, it's not very compelling to pass
boost::use_default as iterator_adaptor's Value
@@ -423,7 +427,7 @@ iterator type argument and reverses its direction of traversal,
since the original iterator and the reversed one have all the same
associated types, iterator_adaptor's delegation of default
types to its Base saves the implementor of
-boost::reverse_iterator from writing
diff --git a/doc/iterator_adaptor.pdf b/doc/iterator_adaptor.pdf
index 4854b0a..1dca935 100755
Binary files a/doc/iterator_adaptor.pdf and b/doc/iterator_adaptor.pdf differ
diff --git a/doc/iterator_adaptor_ref.rst b/doc/iterator_adaptor_ref.rst
index fb6a88c..b8de30d 100644
--- a/doc/iterator_adaptor_ref.rst
+++ b/doc/iterator_adaptor_ref.rst
@@ -23,6 +23,7 @@
explicit iterator_adaptor(Base iter);
Base const& base() const;
protected:
+ typedef iterator_adaptor iterator_adaptor\_;
Base const& base_reference() const;
Base& base_reference();
private: // Core iterator interface for iterator_facade.
diff --git a/doc/iterator_adaptor_tutorial.rst b/doc/iterator_adaptor_tutorial.rst
index ed1aa7e..4106846 100755
--- a/doc/iterator_adaptor_tutorial.rst
+++ b/doc/iterator_adaptor_tutorial.rst
@@ -21,7 +21,7 @@ we're going to pick up right where it left off.
words, the original iterator traverses a one-element array.
You probably didn't think of it this way, but the ``node_base*``
-object which underlies ``node_iterator`` is itself an iterator,
+object that underlies ``node_iterator`` is itself an iterator,
just like all other pointers. If we examine that pointer closely
from an iterator perspective, we can see that it has much in common
with the ``node_iterator`` we're building. First, they share most
@@ -30,9 +30,10 @@ of the same associated types (``value_type``, ``reference``,
core functionality is the same: ``operator*`` and ``operator==`` on
the ``node_iterator`` return the result of invoking the same
operations on the underlying pointer, via the ``node_iterator``\ 's
-|dereference_and_equal|_). However, the ``operator++`` for
-``node_iterator`` behaves differently than for ``node_base*``
-since it follows the ``m_next`` pointer.
+|dereference_and_equal|_). The only real behavioral difference
+between ``node_base*`` and ``node_iterator`` can be observed when
+they are incremented: ``node_iterator`` follows the
+``m_next`` pointer, while ``node_base*`` just applies an address offset.
.. |dereference_and_equal| replace:: ``dereference`` and ``equal`` member functions
.. _dereference_and_equal: iterator_facade.html#implementing-the-core-operations
@@ -60,16 +61,12 @@ behaviors other than ``increment``. The implementation of
private:
struct enabler {}; // a private type avoids misuse
- typedef boost::iterator_adaptor<
- node_iter, Value*, boost::use_default, boost::forward_traversal_tag
- > super_t;
-
public:
node_iter()
- : super_t(0) {}
+ : node_iter::iterator_adaptor_(0) {}
explicit node_iter(Value* p)
- : super_t(p) {}
+ : node_iter::iterator_adaptor_(p) {}
template
node_iter(
@@ -79,14 +76,21 @@ behaviors other than ``increment``. The implementation of
, enabler
>::type = enabler()
)
- : super_t(other.base()) {}
+ : node_iter::iterator_adaptor_(other.base()) {}
private:
friend class boost::iterator_core_access;
void increment() { this->base_reference() = this->base()->next(); }
};
-You can see an example program which exercises this version of the
+Note the use of ``node_iter::iterator_adaptor_`` here: because
+``iterator_adaptor`` defines a nested ``iterator_adaptor_`` type
+that refers to itself, that gives us a convenient way to refer to
+the complicated base class type of ``node_iter``. [Note:
+this technique is known not to work with Borland C++ 5.6.4 and
+Metrowerks CodeWarrior versions prior to 9.0]
+
+You can see an example program that exercises this version of the
node iterators `here`__.
__ ../example/node_iterator3.cpp
@@ -102,7 +106,7 @@ iterator type argument and reverses its direction of traversal,
since the original iterator and the reversed one have all the same
associated types, ``iterator_adaptor``\ 's delegation of default
types to its ``Base`` saves the implementor of
-``boost::reverse_iterator`` from writing
+``boost::reverse_iterator`` from writing:
.. parsed-literal::
diff --git a/doc/iterator_facade.html b/doc/iterator_facade.html
index 1c51e9a..207485b 100644
--- a/doc/iterator_facade.html
+++ b/doc/iterator_facade.html
@@ -3,7 +3,7 @@
-
+
Iterator Facade
@@ -12,7 +12,6 @@
-
Iterator Facade
@@ -32,6 +31,7 @@ Railway Operation and Construction
Copyright David Abrahams, Jeremy Siek, and Thomas Witt 2003. All rights reserved
+
@@ -43,7 +43,7 @@ and associated types, to be supplied by a derived iterator class.
@@ -143,7 +143,7 @@ of the derived iterator type. These member functions are described
briefly below and in more detail in the iterator facade
requirements.
-
+
@@ -261,7 +261,6 @@ are described in terms of a set of requirements, which must be
satisfied by the iterator_facade implementation.
The term mutable iterator means an iterator through which
the object it references (its "referent") can be modified. A
constant iterator is one which doesn't allow modification of
@@ -1139,7 +1140,7 @@ class const_node_iterator
};