some "generator" changes

[SVN r11032]

tmpw2001-paper/iter-adaptor.tex

@@ -61,22 +61,21 @@ contexts.
 \subsection{Iterators}
 
 The power of iterators derives from several key
-features:\begin{itemize}
+features:
+\begin{itemize}
+\item Iterators form a rich \emph{family} of concepts\footnote{We use
+    the term \emph{concept} to mean a set of requirements that a type
+    must satisfy to be used with a particular template parameter.}
+  whose functionality varies along several axes: movement,
+  dereferencing, and associated type exposure.
   
-\item Iterators form a rich \emph{family} of concepts whose
+\item The iterator concepts of the \Cpp\ standard form a refinement
-  functionality varies along several axes: movement, dereferencing,
+  hierarchy which allows the same basic interface elements to
-  and associated type exposure\footnote{We use the term \emph{concept}
+  implement diverse functionality.
-    to mean a set of requirements that a type must
+  
-    satisfy to be used with a particular template parameter.}.
+\item Because built-in pointer types model the
-
+  \stlconcept{RandomAccessIterator} concept, iterators can be both
- \item The iterator concepts of the \Cpp\
+  efficient and convenient to use.
-standard form a refinement hierarchy which allows the same basic
-interface elements to implement diverse functionality.
-
- \item Because
-built-in pointer types model the \stlconcept{RandomAccessIterator}
-concept, iterators can be both efficient and convenient to use.
-
 \end{itemize}
 
 The \Cpp\ Standard Library contains a wide variety of useful
@@ -408,15 +407,15 @@ namespace boost {
 
 In Section~\ref{sec:iterator-policies-class} we showed how to create
 the policy class for the transform iterator; the next step is to use
-the \iteratoradaptor\ template to construct the actual iterator
+the \iteratoradaptor\ template to construct the actual iterator type.
-type. The best way to package the construction of the transform
+The best way to package the construction of the transform iterator is
-iterator is to create a \emph{type generator}: a class
+to create a \emph{type generator}: a class template whose sole purpose
-template whose sole purpose is to simplify the instantiation of some
+is to simplify the instantiation of some other complicated class
-other complicated class template. It fulfills the same need as a
+template. It fulfills the same need as a template typedef would, if
-template typedef would, if that were part of the \Cpp\ language.  The
+that were part of the \Cpp\ language.  The first template parameter to
-first template parameter to the generator is the type of the function
+the type generator is the type of the function object and the second
-object and the second is the base iterator type.  The following code
+is the base iterator type.  The following code shows the type
-shows the type generator for the transform iterator.
+generator for the transform iterator.
 
 {\footnotesize
 \begin{verbatim}
@@ -452,7 +451,7 @@ the base iterator.
 
 It is tempting to create a \code{transform\_\-iterator} class template
 which is derived from \iteratoradaptor\, instead of using the
-generator.  This approach does not work, for example, because the
+type generator.  This approach does not work, for example, because the
 return type of \code{operator++} of an iterator is required to be the
 same iterator type, while in this case the return type would be
 \iteratoradaptor\ and not \code{transform\_\-iterator}.
@@ -521,21 +520,21 @@ In the example above, \code{std::back\_\-inserter} is a type of
 function called an \emph{object generator} which returns an object of
 type \code{std::back\_\-insert\_\-iterator<my\_\-list>}. An object
 generator allows the user to build adapted types ``on the fly'' and
-pass them directly to functions, so that no declaration is
+pass them directly to functions, so that no declaration is needed.
-needed. This idiom is especially convenient in the case of iterators,
+This idiom is especially convenient in the case of iterators, since so
-since so many algorithms are implemented in terms of iterator
+many algorithms are implemented in terms of iterator ranges. We
-ranges. We therefore recommend that iterator implementers create an
+therefore recommend that iterator implementers create an object
-object generator for their iterators. The generator
+generator for their iterators. The object generator function for the
-function for the transform iterator adaptor,
+transform iterator adaptor, \code{make\_\-transform\_\-iterator}, is
-\code{make\_\-transform\_\-iterator}, is shown below.\footnote{
+shown below.\footnote{ Although there is precedent in the standard for
-Although there is precedent in the standard for calling such an object
+  calling such an object generator, simply
-generator, simply ``\code{transform\_iterator()}''
+  ``\code{transform\_iterator()}'' (e.g.
-(e.g. \code{std::back\_\-inserter}), the standard also uses the more
+  \code{std::back\_\-inserter}), the standard also uses the more
-explicit ``\code{make\_}'' prefix (e.g. \code{std::make\_pair()}) and
+  explicit ``\code{make\_}'' prefix (e.g. \code{std::make\_pair()})
-occasionally also reserves the simple name for the iterator type itself
+  and occasionally also reserves the simple name for the iterator type
-(e.g. \code{std::reverse\_iterator}).  In the end, the authors felt
+  itself (e.g. \code{std::reverse\_iterator}).  In the end, the
-that explicit was better than implicit and decided to use the
+  authors felt that explicit was better than implicit and decided to
-``\code{make\_}'' prefix for object generators.  }
+  use the ``\code{make\_}'' prefix for object generators.  }
 
 {\footnotesize
 \begin{verbatim}