diff --git a/tmpw2001-paper/Makefile b/tmpw2001-paper/Makefile deleted file mode 100644 index 9b308bd..0000000 --- a/tmpw2001-paper/Makefile +++ /dev/null @@ -1,75 +0,0 @@ -# -*- 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 deleted file mode 100644 index fc94ba3..0000000 --- a/tmpw2001-paper/defs.tex +++ /dev/null @@ -1,36 +0,0 @@ - -\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 deleted file mode 100644 index fa501da..0000000 --- a/tmpw2001-paper/iter-adaptor.tex +++ /dev/null @@ -1,423 +0,0 @@ - -% 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 deleted file mode 100644 index d67917c..0000000 --- a/tmpw2001-paper/netobjectdays.cls +++ /dev/null @@ -1,102 +0,0 @@ -% 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 deleted file mode 100644 index cc0bd3b..0000000 --- a/tmpw2001-paper/refs.bib +++ /dev/null @@ -1,94 +0,0 @@ - -@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 deleted file mode 100644 index ea2a0e8..0000000 --- a/tmpw2001-paper/tmpw00.bib +++ /dev/null @@ -1,249 +0,0 @@ - - - -@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." -} -