diff --git a/tmpw2001-paper/Makefile b/tmpw2001-paper/Makefile new file mode 100644 index 0000000..9b308bd --- /dev/null +++ b/tmpw2001-paper/Makefile @@ -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 + diff --git a/tmpw2001-paper/defs.tex b/tmpw2001-paper/defs.tex new file mode 100644 index 0000000..fc94ba3 --- /dev/null +++ b/tmpw2001-paper/defs.tex @@ -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}}} diff --git a/tmpw2001-paper/iter-adaptor.tex b/tmpw2001-paper/iter-adaptor.tex new file mode 100644 index 0000000..fa501da --- /dev/null +++ b/tmpw2001-paper/iter-adaptor.tex @@ -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 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} parameter is used +to convey the appropriate return type. The complete code for +\code{transform\_iterator\_policies} is: + +{\footnotesize +\begin{verbatim} + template + struct transform_iterator_policies : public default_iterator_policies + { + transform_iterator_policies() { } + + transform_iterator_policies(const AdaptableUnaryFunction& f) + : m_f(f) { } + + template + Reference dereference(type, 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 + struct transform_iterator_generator + { + typedef typename AdaptableUnaryFunction::result_type value_type; + public: + typedef iterator_adaptor, + 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 + typename transform_iterator_generator::type + make_transform_iterator(Iterator base, + const AdaptableUnaryFunction& f = AdaptableUnaryFunction()) + { + typedef typename transform_iterator_generator::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 + #include + #include + #include + + 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(), 2)), + boost::make_transform_iterator(x + N, + std::bind1st(std::multiplies(), 2)), + std::ostream_iterator(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} diff --git a/tmpw2001-paper/netobjectdays.cls b/tmpw2001-paper/netobjectdays.cls new file mode 100644 index 0000000..d67917c --- /dev/null +++ b/tmpw2001-paper/netobjectdays.cls @@ -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} diff --git a/tmpw2001-paper/refs.bib b/tmpw2001-paper/refs.bib new file mode 100644 index 0000000..cc0bd3b --- /dev/null +++ b/tmpw2001-paper/refs.bib @@ -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, +} diff --git a/tmpw2001-paper/tmpw00.bib b/tmpw2001-paper/tmpw00.bib new file mode 100644 index 0000000..ea2a0e8 --- /dev/null +++ b/tmpw2001-paper/tmpw00.bib @@ -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$ 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$ 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." +} +