mirror of
https://github.com/boostorg/utility.git
synced 2025-09-26 09:10:54 +02:00
Added a mention of the pair_generator; updated conclusion to stress Policy Adaptor.
[SVN r11039]
This commit is contained in:
@@ -211,8 +211,8 @@ iterator types from scratch), but a generalized iterator
|
|||||||
\emph{adaptor} is even more useful. An adaptor generator allows one to
|
\emph{adaptor} is even more useful. An adaptor generator allows one to
|
||||||
build whole families of iterator instances based on existing
|
build whole families of iterator instances based on existing
|
||||||
iterators. In the Boost Iterator Adaptor Library, the
|
iterators. In the Boost Iterator Adaptor Library, the
|
||||||
\iteratoradaptor\ class template plays the roles of both an iterator
|
\iteratoradaptor\ class template plays the roles of both iterator
|
||||||
generator and an iterator adaptor generator. The behaviors of
|
generator and iterator adaptor generator. The behaviors of
|
||||||
\iteratoradaptor{} instances are supplied through a policies
|
\iteratoradaptor{} instances are supplied through a policies
|
||||||
class~\cite{alexandrescu01:_modern_cpp_design} which allows
|
class~\cite{alexandrescu01:_modern_cpp_design} which allows
|
||||||
users to specialize adaptation. Users go beyond generating new
|
users to specialize adaptation. Users go beyond generating new
|
||||||
@@ -883,7 +883,7 @@ list using a template meta-program utility class named
|
|||||||
\end{verbatim}
|
\end{verbatim}
|
||||||
}
|
}
|
||||||
|
|
||||||
\noindent So, for example, to retrieve the argument for the
|
\noindent For example, to retrieve the argument for the
|
||||||
\valuetype\ we write the following:
|
\valuetype\ we write the following:
|
||||||
|
|
||||||
{\footnotesize
|
{\footnotesize
|
||||||
@@ -986,6 +986,32 @@ templates (as shown in the previous Subsection). This allows the same
|
|||||||
function template to provide the implementation of all the
|
function template to provide the implementation of all the
|
||||||
combinations of constant and mutable iterator interaction.
|
combinations of constant and mutable iterator interaction.
|
||||||
|
|
||||||
|
Many of the specialized adaptors in the Boost Iterator Adaptor Library supply an
|
||||||
|
additional type generator (as described in \S\ref{sec:iter-type-generator}) for
|
||||||
|
matched pairs of constant and mutable iterators. For example, an ``indirect
|
||||||
|
container'' using a matched pair of indirect iterators might be declared as
|
||||||
|
follows:
|
||||||
|
|
||||||
|
% jeremy, I didn't want to do this, but it was breaking this tiny example
|
||||||
|
% across pages. Do you know a better way to stop that?
|
||||||
|
% \newpage\
|
||||||
|
% when I added this, it broke an example at the end of the next page across
|
||||||
|
% pages, so I just bailed.
|
||||||
|
|
||||||
|
{\footnotesize
|
||||||
|
\begin{verbatim}
|
||||||
|
template <class BaseContainer>
|
||||||
|
struct indirect
|
||||||
|
{
|
||||||
|
typedef typename BaseContainer::iterator base_iterator;
|
||||||
|
typedef indirect_iterator_pair_generator<base_iterator> iterator_generator;
|
||||||
|
|
||||||
|
typedef typename iterator_generator::iterator iterator;
|
||||||
|
typedef typename iterator_generator::const_iterator const_iterator;
|
||||||
|
...
|
||||||
|
};
|
||||||
|
\end{verbatim}
|
||||||
|
}
|
||||||
|
|
||||||
\subsection{Redundant Operators}
|
\subsection{Redundant Operators}
|
||||||
|
|
||||||
@@ -1181,11 +1207,10 @@ policies class) for the iterator, and then the
|
|||||||
\iteratoradaptor\ takes care of most of the implementation
|
\iteratoradaptor\ takes care of most of the implementation
|
||||||
details.
|
details.
|
||||||
|
|
||||||
Taking a step back, the design approach was to create a canonical
|
Taking a step back, the Policy Adaptor design pattern allowed us to easily
|
||||||
implementation of a concept (iterator) and then delegate the core
|
produce both new models of the iterator concept, and new iterator adaptors. This
|
||||||
implementation issues to a policies class. This approach can be
|
strategy can be applied in situations where there is large family of components
|
||||||
applied in situations where there is large family of components that
|
that share the same interface. For example, we plan on applying this design
|
||||||
share the same interface. For example, we plan on applying this design
|
|
||||||
approach to containers and algebraic types.
|
approach to containers and algebraic types.
|
||||||
|
|
||||||
\bibliographystyle{abbrv}
|
\bibliographystyle{abbrv}
|
||||||
|
Reference in New Issue
Block a user