boost_mirror/utility
1
0
Fork 0
mirror of https://github.com/boostorg/utility.git synced 2025-05-09 15:04:00 +00:00
Code Issues Packages Projects Releases Wiki Activity

files for the tmpw2001 paper about iterator adaptors

Browse Source 
[SVN r10278]
This commit is contained in:
Jeremy Siek 2001-06-06 19:08:51 +00:00
parent b7c8e0c17f
commit 9c2549bd00
6 changed files with 979 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
tmpw2001-paper/Makefile Normal file
View File

@ -0,0 +1,75 @@
# -*- makefile -*-
DVIPS = dvips
LATEX = pdflatex
LATEXOUT = pdf
RESULT = pdf
#LATEX = latex
#LATEXOUT = dvi
#RESULT = ps
.SUFFIXES: .tex .dvi .ps .pdf .c .lg .eps
.c.lg:
lgrind -i -o $*.lg -a -lc++ $*.c
.eps.pdf:
epstopdf $*.eps
.tex.pdf:
@ if test ! -f $*.ind; then echo "" > $*.ind; fi
@ $(LATEX) $*
@ if ( grep 'Writing index file' $*.log > /dev/null ); \
then makeindex $* ; $(LATEX) $* ; fi
@ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \
then $(LATEX) $* ; fi
@ if ( grep 'LaTeX Warning: Citation' $*.log > /dev/null ); \
then bibtex $* ; $(LATEX) $* ; fi
@ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \
then $(LATEX) $* ; fi
@ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \
then $(LATEX) $* ; fi
@ if ( grep 'LaTeX Warning: Label(s) may' $*.log > /dev/null ); \
then $(LATEX) $* ; fi
.dvi.ps:
$(DVIPS) -o $*.ps $*
.ps.pdf:
distill -v -maxsubsetpct 99 -subsetfonts on -pairs $*.ps $*.pdf
SRCCODE =
#
# Default rule
#
default: iter-adaptor.$(RESULT)
#
# LaTeX stuff
#
TEX = iter-adaptor.tex
iter-adaptor.dvi: $(TEX) $(SRCCODELG)
iter-adaptor.ps: iter-adaptor.dvi
iter-adaptor.pdf: $(PDFPICT) $(TEX) $(SRCCODELG)
dist: iter-adaptor.ps iter-adaptor.pdf
mkdir -p iter-adaptor
cp $(TEX) $(SRCCODELG) $(EPS) $(PS) \
iter-adaptor.bbl iter-adaptor.ps iter-adaptor.pdf \
iter-adaptor
tar cvf - ./iter-adaptor | gzip > iter-adaptor.tar.gz
#
# Standard rules
#
clean:
/bin/rm -f *.dvi *.o *.ps *.pdf *.log *.blg *.bbl *.aux *~ *.out *.ind

36
tmpw2001-paper/defs.tex Normal file
View File

@ -0,0 +1,36 @@
\usepackage{times}
\newif\ifpdf
\ifx\pdfoutput\undefined
\pdffalse
\else
\pdfoutput=1
\pdftrue
\fi
\ifpdf
\usepackage[
pdftex,
colorlinks=true,
linkcolor=blue,filecolor=blue,pagecolor=blue,urlcolor=blue
]{hyperref}
\fi
\ifpdf
\newcommand{\concept}[1]{\hyperref[concept:#1]{\textsf{#1}}}
\newcommand{\stlconcept}[1]{\href{http://www.sgi.com/Technology/STL/#1.html}{\textsf{#1}}}
\newcommand{\link}[2]{\hyperref[#1]{#2}}
\else
\newcommand{\concept}[1]{\textsf{#1}}
\newcommand{\stlconcept}[1]{\textsf{#1}}
\newcommand{\href}[2]{#2}
\newcommand{\link}[2]{#2}
\fi
\newcommand{\code}[1]{{\small \texttt{#1}}}
\newcommand{\Note}[1]{\marginpar{\begin{flushleft}%
{%%\tiny %%\footnotesize
{\bf Note:} #1}%
\end{flushleft}}}

423
tmpw2001-paper/iter-adaptor.tex Normal file
View File

@ -0,0 +1,423 @@
% Introduction/Motivation, etc. (Dave & Jeremy)
% iterator policies (Dave)
% default policies
% type<> wrapper
% \cite{alexandrescu01:_modern_cpp_design}
% iterator_comparisons base (B&N) (Jeremy) \cite{Barton94}
% workaround for g++ compiler bug with friend functions?
% operator_array_proxy (Dave)
% default pointer/reference type selection (Dave)
% wrapping non-iterators (count_iterator) (Jeremy)
% named template parameters (Jeremy)
% operator[] return type (Dave)
% the static asserts (Dave)
% generators (Jeremy)
% type generators
% tempting to try to use inheritance to replace
% templated typedef, but that doesn't work.
% object generators
% const/non-const interoperability (Dave)
% implementing const/mutable iterators with the same class
% common mistake is to make the return type of operator*()
% depend on whether the iterator object is const/non-const.
% See the transform iterator in \cite{TMPW00:Weiser}
% custom iterators \cite{TMPW00:Baus}
% generating iterators
% line iterator \cite{austern99:_gener_progr_stl}
% constant iterator \cite{koenig97:_rumin_cpp}
% reverse iterator, front_insert_iterator, back_insert_iterator,
% insert_iterator \cite{iso98:_cpp_final_draft_standard}
% view iterators
% \cite{TMPW00:Weiser}
% future work, container adaptors
\documentclass{netobjectdays}
\input{defs}
\begin{document}
\title{Generating Iterator Types}
\author{David Abrahams$^\dag$ and Jeremy Siek$^\ddag$ \\
\\
$^\dag$ Altra Broadband \\
\texttt{abrahams@altrabroadband.com}\\
\\
$^\ddag$ Computer Science Department \\
Indiana University \\
Lindley Hall \\
150 S. Woodlawn Ave. \\
Bloomington, IN\ \ 47405-7104\\
\texttt{jsiek@cs.indiana.edu}
}
\maketitle
\begin{abstract}
The iterator abstraction is one of the most commonly used in
programming and a considerable amount of time is spent building new
iterator types. However, implementing an iterator type that satisfies
the C++ Standard requirements for an iterator can be
challenging. There are a number of common mistakes that people make,
and there are necessary complexities in a C++ Standard conforming
implementation that one would rather not have to think about. In this
paper we present the iterator type generator in the Boost Iterator
Adaptor Library. This generator simplifies the creation of iterators;
it automates the error-prone and redundant parts of the implementation
and greatly simplifies the creation of iterator types that are
variations on other iterators (creating iterator adaptors). The
design of the Iterator Adaptor Library is an example of policy-based
design, and the implementation employs template meta-programming.
\end{abstract}
\section{Introduction}
%- defaults make it easy to adapt an iterator
%- extensions from base operations to other operations make it
% easier to create iterators
Iterators play an important role in modern C++ programing. The
iterator is the central abstraction of the algorithms of the Standard
Library and creating new iterator types and adapting old ones are
common tasks for C++ programmers. There are plenty of examples of
custom-made iterators in the literature: the
\code{line\_iterator}~\cite{austern99:_gener_progr_stl},
\code{Constant\_iterator}~\cite{koenig97:_rumin_cpp},
\code{istream\_iterator} and
\code{ostream\_iterator}~\cite{iso98:_cpp_final_draft_standard} to
name a few. Also a growing number of generic iterator adaptors are
available: \code{Checked\_iter}~\cite{stroustrup00:_cpp_prog_lang},
iterators of the View Template Library~\cite{TMPW00:Weiser}, custom
and smart iterators~\cite{becker98:_smart_iteraters,TMPW00:Baus},
compound iterators~\cite{alexandrescu98:_compound_iters}, and several
iterators in the MTL~\cite{siek99:_scitools}.
For an iterator to be usable with the Standard algorithms (and other
generic algorithms in third-party libraries), it must fulfill the
Standard requirements for an iterator type, which range from the few
requirements of an \stlconcept{InputIterator} to the many requirements
of a \stlconcept{RandomAccessIterator}. Implementing an iterator class
that meets these requirements is a tedious and error-prone task
despite the fact that most iterators are conceptually simple.
\subsection{Redundant Operators}
Perhaps the most obvious of reasons that implementing an iterator can
be tediuos is that there are lots of redundant operators. That is,
there are many operators that can be trivially defined in terms of
other operators. For example, the \code{operator++(int)} is often best
implemented in terms of \code{operator++()} as the example below
shows.
{\footnotesize
\begin{verbatim}
class iter {
// ...
iter& operator++() { /* ... */ return *this; }
iter operator++(int) { iter tmp(*this); ++*this; return tmp; }
};
\end{verbatim}
}
For a full \stlconcept{RandomAccessIterator}, there are a total of 17
operators. 7 of the operators are fundamental while the other 10 are
redundant.
% 7 core operations
% 10 derived operations
% \code{operator->}
% \code{operator[]}
% \code{operator++(int)},
% \code{operator--(int)},
% \code{operator-=},
% \code{operator+},
% \code{operator!=},
% \code{operator>},
% \code{operator<=},
% \code{operator>=}
\subsection{Delagation of Operators for Iterator Adaptors}
It is often the case that an iterator adaptor changes the meaning of
one or two operators while leaving the rest of the operators defined
in the same way as the underlying iterator. This is typically
implemented with delegating functions. The following example shows an
excerpt from an \code{indirect\_iterator} adaptor, which takes an
iterator over pointers and creates an iterator over the things pointed
to. The \code{operator*} is changed to dereference twice but all the
other operators stay the same. Writing all of the delegating functions
for the \code{indirect\_iterator} would be a tedious task.
{\footnotesize
\begin{verbatim}
template <class Iterator> class indirect_iterator {
public:
// Adapt the meaning of dereference
reference operator*() const {
return **iter; // dereference twice
}
// Delegating the implementation to the underlying iterator.
iter_adaptor& operator++() { ++iter; return *this; }
iter_adaptor& operator--() { --iter; return *this; }
// delegate for all the other operators...
private:
Iterator iter;
};
\end{verbatim}
}
\subsection{Iterator Complexities}
In addition to the tedious aspects of iterator implementation, there
are some complexities that trip up even the most experienced of
programmers.
\subsubsection{Constant/Mutable Iterator Interactions}
One of the main situations in which iterators are used is inside
containers. These iterators usually come in pairs: a constant iterator
type and a mutable iterator type. It is desirable to allow the
constant and mutable iterators to interoperate in terms of their
binary operators. For example, suppose that you are implementing a
container type \code{C}. Then you ought to define the following four
version of \code{operator==}.
{\footnotesize
\begin{verbatim}
bool operator==(const C::iterator& x, const C::iterator& y);
bool operator==(const C::const_iterator& x, const C::iterator& y);
bool operator==(const C::iterator& x, const C::const_iterator& y);
bool operator==(const C::const_iterator& x, const C::const_iterator& y);
\end{verbatim}
}
Implementers often forget to define the operators for const/mutable
iterator interaction. In addition, iterator adaptors applied to these
kinds of iterators should propagate the ability to interact. For
example, a reverse iterator adaptor applied to \code{C::iterator} and
\code{C::const\_iterator} should result in reverse iterator types that
also have operators defined for the const/mutable interactions.
\subsubsection{Constant/Mutable Iterator Implementation}
Another subtlety in the implementation of iterators is how the the
distinction between constant and mutable iterators affects the
implementation. It is obvious that a constant iterator should have a
const \code{reference} type, while a mutable iterator should have a
non-const \code{reference}, though in other regards the constant and
mutable versions of an iterator are the same. It is therefore
desirable to implement both versions of the iterator with a single
class. It is possible to do this, however some care must be taken.
One common mistake is that the programmer will confuse the difference
between a const iterator object and a constant iterator. Such a
misunderstanding can, for example, lead to an iterator class that has
two versions of \code{operator*}, one that is a const member function
and one that is not.
{\footnotesize
\begin{verbatim}
// this is a mistake
reference operator*();
const_reference operator*() const;
\end{verbatim}
}
The right way to implement both a constant and mutable iterators using
the same class is to make the iterator a class template and make the
reference type a parameter. To create the constant iterator a const
reference would be used as the template argument and to create the
mutable iterator a non-const reference would be used as the template
argument. There should be only one \code{operator*} that returns the
\code{reference} type and the member function should be const since
dereferencing an iterator does not change the state of the iterator
object itself (unlike \code{operator++}).
{\footnotesize
\begin{verbatim}
// this is right
reference operator*() const;
\end{verbatim}
}
\subsubsection{Input Iterators and \code{operator->}}
When creating an iterator adaptor that can accept an
\stlconcept{InputIterator} as the adapted type some extra care must be
taken in the implementation of \code{operator->}. \Note{Dave fills in
the rest}
% Automatic implementation of redundant operators
% Default delegation to adapted iterator
% complexities:
% const-non const interaction
% const/mutable iterator distinction
% input iterator \code{operator->}
\section{The Boost \code{iterator\_adaptor}}
\subsection{Example}
It is often useful to automatically apply some function to the value
returned by dereferencing an iterator. The transform iterator of the
Iterator Adaptor Library makes it easy to create an iterator adaptor
which does just that. Here we will show how easy it is to implement
the transform iterator using the
\code{iterator\_adaptor} template.
We want to be able to adapt a range of iterators and functions, so the
policies class will have a template parameter for the function type
and it will have a data member of that type. We know that the function
takes one argument and that we'll need to be able to deduce the
\code{result\_type} of the function so we can use it for the adapted
iterator's \code{value\_type}. \stlconcept{AdaptableUnaryFunction} is
the \textsf{concept}\cite{austern99:_gener_progr_stl} that fulfills
those requirements.
To implement a transform iterator we will only change one of the base
iterator's behaviors, so the \code{transform\_iterator\_policies}
class can inherit the rest from \code{default\_iterator\_policies}. We
will define the \code{dereference()} member function, which is used
to implement \code{operator*()} of the adapted iterator. The
implementation will dereference the base iterator and apply the
function object. The \code{type<Reference>} parameter is used
to convey the appropriate return type. The complete code for
\code{transform\_iterator\_policies} is:
{\footnotesize
\begin{verbatim}
template <class AdaptableUnaryFunction>
struct transform_iterator_policies : public default_iterator_policies
{
transform_iterator_policies() { }
transform_iterator_policies(const AdaptableUnaryFunction& f)
: m_f(f) { }
template <class Reference, class BaseIterator>
Reference dereference(type<Reference>, const BaseIterator& i) const
{ return m_f(*i); }
AdaptableUnaryFunction m_f;
};
\end{verbatim}
}
The next step is to use the \code{iterator\_adaptor} template to
construct the transform iterator type. The nicest way to package the
construction of the transform iterator is to create a \emph{type
generator}, which is a class template whose sole purpose is to
simplify the instantiation of some other complicated class
template. It fulfills the same need as a templated typedef would if
that were part of the {C++} language.
The first template parameter to the generator will be the type of the
function object and the second will be the base iterator type. We use
\code{iterator\_adaptor} to define the transform iterator type as a
nested \code{typedef} inside the
\code{transform\_iterator\_generator} class. Because the function may
return by-value, we must limit the \code{iterator\_category} to
\stlconcept{InputIterator}, and the iterator's \code{reference} type cannot be a
true reference (the standard allows this for input iterators), so in
this case we can use few of \code{iterator\_adaptor}'s default template
arguments.
{\footnotesize
\begin{verbatim}
template <class AdaptableUnaryFunction, class Iterator>
struct transform_iterator_generator
{
typedef typename AdaptableUnaryFunction::result_type value_type;
public:
typedef iterator_adaptor<Iterator,
transform_iterator_policies<AdaptableUnaryFunction>,
value_type, value_type, value_type*, std::input_iterator_tag> type;
};
\end{verbatim}
}
As a finishing touch, we will create an
\textsf{object generator} for the transform iterator, which
is a function that makes it more convenient to create objects of some
class template.
{\footnotesize
\begin{verbatim}
template <class AdaptableUnaryFunction, class Iterator>
typename transform_iterator_generator<AdaptableUnaryFunction,
Iterator>::type
make_transform_iterator(Iterator base,
const AdaptableUnaryFunction& f = AdaptableUnaryFunction())
{
typedef typename transform_iterator_generator<AdaptableUnaryFunction,
Iterator>::type result_t;
return result_t(base, f);
}
\end{verbatim}
}
Here is an example that shows how to use a transform iterator to
iterate through a range of numbers, multiplying each of them by 2
and printing the result to standard output.
{\footnotesize
\begin{verbatim}
#include <functional>
#include <algorithm>
#include <iostream>
#include <boost/iterator_adaptors.hpp>
int main(int, char*[])
{
int x[] = { 1, 2, 3, 4, 5, 6, 7, 8 };
const int N = sizeof(x)/sizeof(int);
std::cout << "multiplying the array by 2:" << std::endl;
std::copy(boost::make_transform_iterator(x,
std::bind1st(std::multiplies<int>(), 2)),
boost::make_transform_iterator(x + N,
std::bind1st(std::multiplies<int>(), 2)),
std::ostream_iterator<int>(std::cout, " "));
std::cout << std::endl;
return 0;
}
\end{verbatim}
}
\noindent This output is:
{\footnotesize
\begin{verbatim}
2 4 6 8 10 12 14 16
\end{verbatim}
}
\bibliographystyle{abbrv}
\bibliography{refs,tmpw00}
\end{document}

102
tmpw2001-paper/netobjectdays.cls Normal file
View File

@ -0,0 +1,102 @@
% Paper Formatting according to requirements of Net.Objectdays 2000
\LoadClass[10pt]{article}
\pagestyle{empty}
% ---------------------------------------------------------------------
\textheight193mm
\textwidth122mm
\oddsidemargin44mm
\hoffset-1in \voffset-1in
\topmargin52mm
\headsep0pt
\headheight0pt
% ---------------------------------------------------------------------
\renewcommand\maketitle{\par
\begingroup
\renewcommand\thefootnote{\@fnsymbol\c@footnote}%
\def\@makefnmark{\rlap{\@textsuperscript{\normalfont\@thefnmark}}}%
\long\def\@makefntext##1{\parindent 1em\noindent
\hb@xt@1.8em{%
\hss\@textsuperscript{\normalfont\@thefnmark}}##1}%
\if@twocolumn
\ifnum \col@number=\@ne
\@maketitle
\else
\twocolumn[\@maketitle]%
\fi
\else
\newpage
\global\@topnum\z@ % Prevents figures from going at top of page.
\@maketitle
\fi
\thispagestyle{empty}\@thanks
\endgroup
\setcounter{footnote}{0}%
\global\let\thanks\relax
\global\let\maketitle\relax
\global\let\@maketitle\relax
\global\let\@thanks\@empty
\global\let\@author\@empty
\global\let\@date\@empty
\global\let\@title\@empty
\global\let\title\relax
\global\let\author\relax
\global\let\date\relax
\global\let\and\relax
}
\date{}
\def\@maketitle{%
\newpage
\null
\vskip 2em%
\begin{center}%
\let \footnote \thanks
{\Large \textbf{\@title} \par}%
\vskip 1.5em%
{\large
\lineskip .5em%
{\normalsize
\begin{tabular}[t]{c}%
\@author
\end{tabular}\par}}%
\vskip 1em%
{\large \@date}%
\end{center}%
\par
\vskip 1.5em}
\renewcommand\section{\@startsection {section}{1}{\z@}%
{-3.5ex \@plus -1ex \@minus -.2ex}%
{2.3ex \@plus.2ex}%
{\normalfont\large\bfseries}}
\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
{-3.25ex\@plus -1ex \@minus -.2ex}%
{1.5ex \@plus .2ex}%
{\normalfont\normalsize\bfseries}}
\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
{-3.25ex\@plus -1ex \@minus -.2ex}%
{1.5ex \@plus .2ex}%
{\normalfont\normalsize\bfseries}}
\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
{3.25ex \@plus1ex \@minus.2ex}%
{-1em}%
{\normalfont\normalsize\bfseries}}
\renewcommand\subparagraph{\@startsection{subparagraph}{5}{\parindent}%
{3.25ex \@plus1ex \@minus .2ex}%
{-1em}%
{\normalfont\normalsize\bfseries}}
\renewcommand{\figurename}{Fig}
\renewcommand{\tablename}{Tab}
\long\def\@makecaption#1#2{%
\vskip\abovecaptionskip
\sbox\@tempboxa{{\small\textbf{#1.} #2}}%
\ifdim \wd\@tempboxa >\hsize
{\small\textbf{#1.} #2}\par
\else
\global \@minipagefalse
\hb@xt@\hsize{\hfil\box\@tempboxa\hfil}%
\fi
\vskip\belowcaptionskip}
\renewenvironment{abstract}
{\list{}{\leftmargin1cm\rightmargin\leftmargin}%
\item\relax{\small \textbf{Abstract.}}}
{\endlist}

94
tmpw2001-paper/refs.bib Normal file
View File

@ -0,0 +1,94 @@
@TechReport{stepa.lee-1994:the.s:TR,
author = "A. A. Stepanov and M. Lee",
title = "{The Standard Template Library}",
institution = "ISO Programming Language C++ Project",
year = "1994",
number = "X3J16/94-0095, WG21/N0482",
month = may,
}
@Book{ austern99:_gener_progr_stl,
author = "Matthew H. Austern",
title = "Generic Programming and the {STL}",
publisher = "Addison-Wesley",
year = 1999,
series = "Professional computing series"
}
@Book{koenig97:_rumin_cpp,
author = {Andrew Koenig and Barbara Moo},
title = {Ruminations on {C++}},
publisher = {Addison Wesley},
year = 1997
}
@Book{iso98:_cpp_final_draft_standard,
author = "International Organization for Standardization
(ISO)",
title = "ISO/IEC Final Draft International Standard 14882:
Programming Language C++",
year = 1998,
address = "1 rue de Varemb\'e, Case postale 56, CH-1211
Gen\`eve 20, Switzerland"
}
@Book{alexandrescu01:_modern_cpp_design,
author = {Andrei Alexandrescu},
title = {Modern {C++} Design},
publisher = {Addison Wesley},
year = 2001
}
@BOOK { Barton94,
AUTHOR = "John Barton and Lee Nackman",
TITLE = "Scientific and Engineering {C++}",
PUBLISHER = "Addison-Wesley",
YEAR = 1994
}
@Book{gamma95:_design_patterns,
author = {Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides},
title = {Design Patterns: Elements of Reusable Object-Oriented Software},
publisher = {Addison-Welsey},
year = 1995,
series = {Professional Computing}
}
@Book{stroustrup00:_cpp_prog_lang,
author = {Bjarne Stroustrup},
title = {The {C++} Programming Language},
publisher = {Addison-Wesley},
year = 2000,
edition = {Special}
}
@Article{alexandrescu98:_compound_iters,
author = {Andrei Alexandrescu},
title = {Compound iterators of STL},
journal = {{C/C++} Users Journal},
year = 1998,
volume = 16,
number = 10,
pages = {79-82},
month = October
}
@Article{becker98:_smart_iteraters,
author = {Thomas Becker},
title = {Smart Iterators and STL},
journal = {{C/C++} Users Journal},
year = 1998,
volume = 16,
number = 9,
month = {September}
}
@InBook{siek99:_scitools,
author = {Jeremy G. Siek and Andrew Lumsdaine},
title = {Modern Software Tools for Scientific Computing},
chapter = {A Modern Framework for Portable High Performance
Numerical Linear Algebra},
publisher = {Birkhauser},
year = 1999,
}

249
tmpw2001-paper/tmpw00.bib Normal file
View File

@ -0,0 +1,249 @@
@InProceedings{TMPW00:Eisenecker,
AUTHOR = "Ulrich W. Eisenecker and Frank Blinn and Krzysztof Czarnecki",
TITLE = "A Solution to the Constructor-Problem of Mixin-Based Programming in {C++}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"Mixin-Based Programming in C++ is a powerful programming style
based on the parameterized inheritance idiom and the composition
of C++ templates. Type expressions describing specific inheritance
hierarchies can be composed either automatically using generative
programming idioms in C++ or manually. Unfortunately, the mixin-based
C++ programming techniques published to date do not adequately support
optional and alternative mixin classes with constructors expecting
varying numbers of arguments, which are common in practice. This
is because the varying base class constructors do not provide a
uniform interface on which the constructors of the derived classes
could rely. This paper discusses several partial solutions to this
problem that were proposed to date and presents a new, complete
solution. The new solution uses generative programming techniques to
automatically generate the appropriate constructors, and this way it
avoids the overhead and clumsiness of instantiating composed mixin
classes in the client code using the partial solutions. In fact,
the new solution allows users to instantiate automatically composed
mixin classes with the simplicity of instantiating concrete classes
from traditional class hierarchies. Finally, the new solution does
not suffer from the scalability problems of the partial solutions."
}
@InProceedings{TMPW00:Berti,
AUTHOR = "Guntram Berti",
TITLE = "Generic Components for Grid Data Structures and Algorithms with {C++}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"Grids are fundamental data structures for representing
geometric structures or their subdivisions. We propose a strategy
for decoupling algorithms working on grids from the details of
grid representations, using a generic programming approach in C++.
Functionality of grid data structures is captured by a small set of
primitives, divided into combinatorial and geometric ones. Special
attention is paid to the generic implementation of grid functions, which
correspond to the notion of mappings from grid elements (e. g. vertices)
to entities of a given type. Experiments indicate that the overhead
of the generic formulation is low and can be completely eliminated in
some cases."
}
@InProceedings{TMPW00:Veldhuizen,
AUTHOR = "Todd L. Veldhuizen",
TITLE = "Five compilation models for {C++} templates",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"This paper proposes an alternate structure for C++ compilers.
Type analysis is removed from the compiler and replaced with a
`type system library' which is treated as source code by the
compiler. Type computations are embedded in the intermediate
language of the compiler, and partial evaluation is used to drive
type analysis and template instantiation. By making simple changes to
the behavior of the partial evaluator, a wide range of compilation
models is achieved, each with a distinct tradeoff of compile time, code
size, and code speed. These models range from pure dynamic typing --
ideal for scripting C++ -- to profile-directed template instantiation.
This approach may solve several serious problems in compiling C++:
it achieves separate compilation of templates, allows template
code to be distributed in binary form by deferring template instantiation
until run time, and reduces the code bloat associated with
templates."
}
@InProceedings{TMPW00:Baus,
AUTHOR = "Christopher Baus and Thomas Becker",
TITLE = "Custom Iterators for the {STL}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"We discuss several kinds of custom iterators for use with the STL
that are substantially different from the iterators that come with
the STL. We present class templates that implement these custom
iterators in a generic manner."
}
@InProceedings{TMPW00:Weiser,
AUTHOR = "Martin Weiser and Gary Powell",
TITLE = "The {View Template Library}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"Views are container adaptors providing access to different
on the fly generated representations of the data in the container they
are applied to. The concept fits nicely into the framework defined by
the STL. This paper explains design, usage, and implementation of the
View Template Library, the currently most advanced implementation of
the views concept."
}
@InProceedings{TMPW00:Striegnitz,
AUTHOR = "J{\"o}rg Striegnitz and Stephen A. Smith",
TITLE = "An Expression Template aware Lambda Function",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"Template libraries such as the STL contain several generic algorithms
that expect functions as arguments and thereby cause frequent use of
function objects. User-defined function objects are awkward because
they must be declared as a class in namespace scope before they may
be used. In this paper, we describe a lambda function for C++, which
allows users to define function objects on the fly, without writing class
declarations. We show that, by using expression templates, the lambda
function can be implemented without hurting the runtime performance of a
program. Expression templates can also help to overcome the performance
penalties that may arise when using expressions over user-defined
types. Thus, we based our approach on PETE which is a framework
that simplifies the addition of expression template functionality to
user-defined classes."
}
@InProceedings{TMPW00:McNamara,
AUTHOR = "Brian McNamara and Yannis Smaragdakis",
TITLE = "Static Interfaces in {C++}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"We present an extensible framework for defining and
using ``static interfaces'' in C++. Static interfaces are especially
useful as constraints on template parameters. That is, in addition to the
usual template $class T$, template definitions can specify that T ``isa''
Foo, for some static interface named Foo. These ``isa-constraints'' can be
based on either inheritance (named conformance: T publicly inherits Foo),
members (structural conformance: T has these member functions with these
signatures), or both. The constraint mechanism imposes no space or time
overheads at runtime; virtual functions are conspicuously absent from
our framework.
We demonstrate two key utilities of static interfaces. First,
constraints enable better error messages with template code. By applying
static interfaces as constraints, instantiating a template with the
wrong type is an error that can be caught at the instantiation point,
rather than later (typically in the bowels of the implementation).
Authors of template classes and template functions can also dispatch
``custom error messages'' to report named constraint violations by
clients, making debugging easier. We show examples of the improvement of
error messages when constraints are applied to STL code.
Second, constraints enable automatic compile-time dispatch of different
implementations of class or function templates based on the named
conformance properties of the template types. For example, $Set<T>$ can be
written to automatically choose the most efficient implementation: use a
hashtable implementation if ``T isa Hashable'', or else a binary search
tree if ``T isa LessThanComparable'' , or else a linked-list if merely ``T
isa EqualityComparable''. This dispatch can be completely hidden from
clients of Set, who just use $Set<T>$ as usual."
}
@InProceedings{TMPW00:Siek,
AUTHOR = "Jeremy Siek and Andrew Lumsdaine",
TITLE = "Concept Checking: Binding Parametric Polymorphism in {C++}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"Generic programming in C++ is characterized by the use of template
parameters to represent abstract data types (or ``concepts'').
However, the C++ language itself does not provide a mechanism for
explicitly handling concepts. As a result, it can be difficult to
insure that a concrete type meets the requirements of the concept it
is supposed to represent. Error messages resulting from incorrect
use of a concrete type can be particularly difficult to decipher.
In this paper we present techniques to check parameters in generic
C++ libraries. Our techniques use standard C++ and introduce no
run-time overhead."
}
@InProceedings{TMPW00:Kuehl,
AUTHOR = "Dietmar K{\"u}hl",
TITLE = "{STL} and {OO} Don't Easily Mix",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/",
ABSTRACT =
"The STL is a powerful tool for many kinds of processing. Unfortunately,
using polymorphic objects with the STL seems not to work: Polymorphic
objects stored in STL containers either get sliced (i.e. only the base
part is copied or assigned but not the derived part) or, when storing
pointers to them instead, are not destroyed. Applying algorithms to
such containers often results in the wrong thing or complex predicate
objects are needed. This article shows how to overcome at least some
of these problems using some adaptors and also outlines a possible
implementation of STL for better integration with polymorphic objects.
The improved integration just acknowledges the distinction between the
object and the entity used to maintain it."
}
@InProceedings{TMPW00:Eichelberger,
AUTHOR = "H. Eichelberger and J. Wolff v. Gudenberg",
TITLE = "{UML} Description of the {STL}",
BOOKTITLE = "First Workshop on {C++} Template Programming,
Erfurt, Germany",
MONTH = "October 10",
YEAR = "2000",
URL = "http://oonumerics.org/tmpw00/eichelberger.pdf",
ABSTRACT =
"In this paper we show how the specification of the
Standard Template Library STL and its implementation can be described
by UML diagrams. We define appropriate stereotypes to
describe STL concepts like containers, iterators, function
objects and global algorithms. For the graphical description of the
implementation of the STL we extend the UML metamodel."
}