<trclass="field"><thclass="field-name">organizations:</th><tdclass="field-body"><aclass="reference"href="http://www.boost-consulting.com">Boost Consulting</a>, Indiana University <aclass="reference"href="http://www.osl.iu.edu">Open Systems
Lab</a>, University of Hanover <aclass="reference"href="http://www.ive.uni-hannover.de">Institute for Transport
<trclass="field"><thclass="field-name">copyright:</th><tdclass="field-body">Copyright David Abrahams, Jeremy Siek, Thomas Witt 2003. All rights reserved</td>
<li><aclass="reference"href="#upgrading-from-the-old-boost-iterator-adaptor-library"id="id12"name="id12">Upgrading from the old Boost Iterator Adaptor Library</a></li>
required to return a reference (and not a proxy) when dereferenced,
it is impossible to capture the capabilities of
<ttclass="literal"><spanclass="pre">vector<bool>::iterator</span></tt> using the C++98 categories. This is the
infamous "<ttclass="literal"><spanclass="pre">vector<bool></span></tt> is not a container, and its iterators
aren't random access iterators", debacle about which Herb Sutter
wrote two papers for the standards comittee (<aclass="reference"href="http://www.gotw.ca/publications/N1185.pdf">n1185</a> and <aclass="reference"href="http://www.gotw.ca/publications/N1211.pdf">n1211</a>),
and a <aclass="reference"href="http://www.gotw.ca/gotw/050.htm">Guru of the Week</a>. New-style iterators go well beyond
patching up <ttclass="literal"><spanclass="pre">vector<bool></span></tt>, though: there are lots of other
iterators already in use which can't be adequately represented by
the existing concepts. For details about the new iterator
<h1><aclass="toc-backref"href="#id7"name="iterator-facade-and-adaptor">Iterator Facade and Adaptor</a></h1>
<p>Writing standard-conforming iterators is tricky, but the need comes
up often. In order to ease the implementation of new iterators,
the Boost.Iterator library provides the <aclass="reference"href="iterator_facade.html"><ttclass="literal"><spanclass="pre">iterator_facade</span></tt></a> class template,
which implements many useful defaults and compile-time checks
designed to help the author iterator ensure that his iterator is
<p>It is also common to define a new iterator that is similar to some
underlying iterator or iterator-like type, but that modifies some
aspect of the underlying type's behavior. For that purpose, the
library supplies the <aclass="reference"href="iterator_adaptor.html"><ttclass="literal"><spanclass="pre">iterator_adaptor</span></tt></a> class template, which is specially
designed to take advantage of as much of the underlying type's
<p>Both <aclass="reference"href="iterator_facade.html"><ttclass="literal"><spanclass="pre">iterator_facade</span></tt></a> and <aclass="reference"href="iterator_adaptor.html"><ttclass="literal"><spanclass="pre">iterator_adaptor</span></tt></a> as well as many of the <aclass="reference"href="#specialized-adaptors">specialized
adaptors</a> mentioned below have been proposed for standardization,
and accepted into the first C++ technical report; see our</p>
<p>The iterator library supplies a useful suite of standard-conforming
iterator templates based on the Boost <aclass="reference"href="#iterator-facade-and-adaptor">iterator facade and adaptor</a>.</p>
<ulclass="simple">
<li><aclass="reference"href="counting_iterator.html"><ttclass="literal"><spanclass="pre">counting_iterator</span></tt></a>: an iterator over a sequence of consecutive values.
Implements a "lazy sequence"</li>
<li><aclass="reference"href="filter_iterator.html"><ttclass="literal"><spanclass="pre">filter_iterator</span></tt></a>: an iterator over the subset of elements of some
sequence which satisfy a given predicate</li>
<li><aclass="reference"href="indirect_iterator.html"><ttclass="literal"><spanclass="pre">indirect_iterator</span></tt></a>: an iterator over the objects <em>pointed-to</em> by the
elements of some sequence.</li>
<li><aclass="reference"href="permutation_iterator.html"><ttclass="literal"><spanclass="pre">permutation_iterator</span></tt></a>: an iterator over the elements of some random-access
sequence, rearranged according to some sequence of integer indices.</li>
<li><aclass="reference"href="reverse_iterator.html"><ttclass="literal"><spanclass="pre">reverse_iterator</span></tt></a>: an iterator which traverses the elements of some
bidirectional sequence in reverse. Corrects many of the
shortcomings of C++98's <ttclass="literal"><spanclass="pre">std::reverse_iterator</span></tt>.</li>
<li><aclass="reference"href="transform_iterator.html"><ttclass="literal"><spanclass="pre">transform_iterator</span></tt></a>: an iterator over elements which are the result of
applying some functional transformation to the elements of an
underlying sequence. This component also replaces the old
<li><aclass="reference"href="iterator_traits.html"><ttclass="literal"><spanclass="pre">iterator_traits.hpp</span></tt></a>: Provides <aclass="reference"href="../../mpl/doc/index.html">MPL</a>-compatible metafunctions which
retrieve an iterator's traits. Also corrects for the deficiencies
of broken implementations of <ttclass="literal"><spanclass="pre">std::iterator_traits</span></tt>.</li>
<li><aclass="reference"href="interoperable.html"><ttclass="literal"><spanclass="pre">interoperable.hpp</span></tt></a>: Provides an <aclass="reference"href="../../mpl/doc/index.html">MPL</a>-compatible metafunction for
<h1><aclass="toc-backref"href="#id12"name="upgrading-from-the-old-boost-iterator-adaptor-library">Upgrading from the old Boost Iterator Adaptor Library</a></h1>
<aclass="target"id="upgrading"name="upgrading"></a><p>If you have been using the old Boost Iterator Adaptor library to
implement iterators, you probably wrote a <ttclass="literal"><spanclass="pre">Policies</span></tt> class which
captures the core operations of your iterator. In the new library
design, you'll move those same core operations into the body of the
iterator class itself. If you were writing a family of iterators,
you probably wrote a <aclass="reference"href="../../../more/generic_programming.html#type_generator">type generator</a> to build the
<ttclass="literal"><spanclass="pre">iterator_adaptor</span></tt> specialization you needed; in the new library
design you don't need a type generator (though may want to keep it
around as a compatibility aid for older code) because, due to the
use of the Curiously Recurring Template Pattern (CRTP) <aclass="citation-reference"href="#cop95"id="id5"name="id5">[Cop95]</a>,
you can now define the iterator class yourself and acquire
functionality through inheritance from <ttclass="literal"><spanclass="pre">iterator_facade</span></tt> or
<ttclass="literal"><spanclass="pre">iterator_adaptor</span></tt>. As a result, you also get much finer control
over how your iterator works: you can add additional constructors,
or even override the iterator functionality provided by the
library.</p>
<p>If you're looking for the old <ttclass="literal"><spanclass="pre">projection_iterator</span></tt> component,
its functionality has been merged into <ttclass="literal"><spanclass="pre">transform_iterator</span></tt>: as
long as the function object's <ttclass="literal"><spanclass="pre">result_type</span></tt> (or the <ttclass="literal"><spanclass="pre">Reference</span></tt>
template argument, if explicitly specified) is a true reference
type, <ttclass="literal"><spanclass="pre">transform_iterator</span></tt> will behave like
<ttclass="literal"><spanclass="pre">projection_iterator</span></tt> used to.</p>
Generated by <aclass="reference"href="http://docutils.sourceforge.net/">Docutils</a> from <aclass="reference"href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source.
