diff --git a/doc/index.html b/doc/index.html new file mode 100755 index 0000000..7d3058b --- /dev/null +++ b/doc/index.html @@ -0,0 +1,185 @@ + + + +
+ + +Authors: | David Abrahams, Jeremy Siek, Thomas Witt | +
---|---|
Contact: | dave@boost-consulting.com, jsiek@osl.iu.edu, witt@ive.uni-hannover.de | +
organizations: | Boost Consulting, Indiana University Open Systems +Lab, University of Hanover Institute for Transport +Railway Operation and Construction | +
date: | $Date$ | +
copyright: | Copyright Dave Abrahams, Jeremy Siek, Thomas Witt 2003. All rights reserved | +
Abstract: | The Boost Iterator Library is a system of concepts which +extend the C++ standard iterator definition and a framework +of components for building iterators based on these +extended concepts. The extended iterator concepts have +been carefully designed so that new-style iterators will be +compatible with old-style algorithms, though algorithms may +need to be updated if they want to take full advantage of +the new-style iterators. Several components of this +library have been proposed for the C++ standard technical +report. The components of the Boost Iterator Library +replace the older Boost Iterator Adaptor Library. | +
---|
The iterator categories defined in C++98 are extremely limiting +because they bind together two orthogonal concepts: traversal and +element access. For example, because a random access iterator is +required to return a reference (and not a proxy) when dereferenced, it +is impossible to capture the capabilities of +vector<bool>::iterator using the C++98 categories. The infamous +"vector<bool> is not a container, and its iterators aren't random +access iterators", debacle about which Herb Sutter wrote two papers +for the standards comittee (n1185 and n1211), and a Guru of the +Week. New-style iterators go well beyond patching up +vector<bool>, 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 concepts, see our
++Standard Proposal For New-Style Iterators+
Writing standard-conforming iterators is tricky. In order to ease the +implementation of new iterators, the iterator library provides the +iterator_facade class template, which implements many useful +defaults and compile-time checks designed to help the author iterator +ensure that his iterator is correct. It is common to define a new +iterator which behaves like another iterator, but modifies some aspect +of its behavior. For that purpose, the library supplies the +iterator_adaptor class template, which is specially designed to +take advantage of as much of the underlying iterator's behavior as +possible.
+Both iterator_facade and iterator_adaptor as well as many of +the specialized adaptors mentioned below have been proposed for +standardization; see our
++Standard Proposal For Iterator Facade and Adaptor+
for more details.
+The iterator library supplies a useful suite of standard-conforming +iterator templates based on the Boost iterator facade and adaptor.
+Turn your policy class into the body of the iterator
+Use transform_iterator with a true reference type for +projection_iterator.
+In 2000 Dave Abrahams was writing an iterator for a container of +pointers, which would access the pointed-to elements when +dereferenced. Naturally, being a library writer, he decided to +generalize the idea and the Boost Iterator Adaptor library was born. +Dave was inspired by some writings of Andrei Alexandrescu and chose a +policy based design (though he probably didn't capture Andrei's idea +very well - there was only one policy class for all the iterator's +orthogonal properties). Soon Jeremy Siek realized he would need the +library and they worked together to produce a "Boostified" version, +which was reviewed and accepted into the library. They wrote a paper +and made several important revisions of the code.
+Eventually, several shortcomings of the older library began to make +the need for a rewrite apparent. Dave and Jeremy started working at +the Santa Cruz C++ committee meeting in 2002, and had quickly +generated a working prototype. Thomas Witt expressed interest and +became the voice of compile-time checking for the project...
+ +