﻿<html>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<head>
<style>BODY, P, DIV, H1, H2, H3, H4, H5, H6, ADDRESS, OL, UL, LI, TITLE, TD, OPTION, SELECT 
{ 
 font-family: Verdana 
}
BODY, P, DIV, ADDRESS, OL, UL, LI, TITLE, TD, OPTION, SELECT  
{  
  font-size: 10pt; 
  margin-top:0pt;  
  margin-bottom:0pt;  
} 
BODY, P
{
  margin-left:0pt; 
  margin-right:0pt;
}
BODY
{
  background: white;
  margin: 6px;
  padding: 0px;
}
h6 { font-size: 10pt }
h5 { font-size: 11pt }
h4 { font-size: 12pt }
h3 { font-size: 13pt }
h2 { font-size: 14pt }
h1 { font-size: 16pt }
blockquote { padding: 10px; border: 1px #DDDDDD dashed }
a img {	border: 0; }
table.zeroBorder {
	border-width: 1px 1px 1px 1px;
	border-spacing: 2px 2px;
	border-style: dotted dotted dotted dotted;
	border-color: gray gray gray gray;
	border-collapse: collapse;
}
table.zeroBorder th {
	border-width: 1px 1px 1px 1px;
	padding: 1px 1px 1px 1px;
	border-style: dotted dotted dotted dotted;
	border-color: gray gray gray gray;
}
table.zeroBorder td {
	border-width: 1px 1px 1px 1px;
	padding: 1px 1px 1px 1px;
	border-style: dotted dotted dotted dotted;
	border-color: gray gray gray gray;
}
.dragBox {
  background-color: #FFFFFF;
  border: 1px solid #000000;
  color: #000000;
  padding: 0px;
  position: absolute;

}
.dragBar {
 background-color: #008080;
  color: #ffffff;
  font-weight: bold;
  padding: 2px 1em 2px 1em;
}
.hiddenStyle {
		visibility: hidden; 
		position: absolute;
		borderRight: black 1px solid;
		borderLeft: black 1px solid;
		borderTop: black 1px solid;
		borderBottom: black 1px solid;
		z-Index: 1;
		paddingRight: 0;
		paddingLeft: 0;
		paddingTop: 0;
		paddingBottom: 0;
		background: white
	}
.misspell { background-image: url('images/misspell.gif'); background-repeat: repeat-x; background-position: bottom }
@media screen {
.pb { border-top: 1px dashed #C0C0C0; border-bottom: 1px dashed #C0C0C0 }
.writely-comment { font-size: 9pt; line-height: 1.4em; padding: 1px; border: 1px dashed #C0C0C0 }
}
@media print {
.pb { border-top: 0px; border-bottom: 0px }
.writely-comment { display: none }
}
@media screen,print {
.pb { height: 1px }
}
</style></head>
<body revision='bcj5zt2cpp5dd'>
<SPAN STYLE="FONT-WEIGHT: bold"> </SPAN>
<DIV CLASS=wish ID=quaternions>
  <PRE>Doc. no.: N2034=06-0104<BR>Date:     2006-06-19<BR>Project:  Programming Language C++<BR>Reply to: Matt Austern &lt;austern@google.com&gt;<B><BR></B></PRE>
  <H1>
    <B> C++0x Standard Library wishlist (revision 6) </B>
  </H1>
  <P>
    This is a list of suggested additions to the standard C++ library for the
    next version of C++ ("C++0x").
  </P>
  <P>
    This list is intended as a stimulus to further work. Some of the items on
    this list already have one or more concrete proposals associated with them,
    others are vague hopes, and most are somewhere in between. Similarly, the
    scope of these items extend from minor changes in an existing interface to
    major research projects. I have listed a name or names for each item, and,
    if relevant, I have listed a paper or papers describing the idea. These
    ideas are not necessarily supported by anyone other than the person who
    suggested them, and you should not assume that any particular item will make
    it into C++0x. The items in this list are in no particular order.
  </P>
  <P>
    &nbsp;<A></A><B> </B>
  </P>
  <H2>
    <B> Categories </B>
  </H2>
  <P>
    Most of the entries in the wish list fall into a small number of general
    categories:
  </P>
  <UL>
    <LI>
      System: Things that can't be done portably in standard C++, such as
      filesystem access, sockets, database access, and persistence.
    <LI>
      Numerics: Numerical computation
    <LI>
      Usability: Usability improvements, particularly for novices.
    <LI>
      Algorithms: Algorithms and data structures<B></B>
  </UL>
  <H2>
    <B> The wish list </B>
  </H2>
  <DIV CLASS=wish ID=containerformatting>
    <B> </B>
    <H3>
      <B> Formatted container output </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Dave Abrahams<B><BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      Simple and uniform display mechanism for arbitrary ordered lists. (Arrays,
      STL containers, pairs, tuples, etc.) cout &lt;&lt; x should "just work"
      for such types.<B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=infiniteprecision>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Infinite-precision integer arithmetic </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Maarten Kronenburg, Bjarne Stroustrup, Matt
      Austern, others<B><BR>
      <B>Paper:</B> </B>N1718, "A Proposal to add the Infinite Precision Integer
      and Rational to the C++ Standard Library", M. J. Kronenburg.<B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=stringinterface>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Uniform use of std::string </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Bjarne Stroustrup<BR>
      Paper:<B><B> </B> </B>
    </P>
    <B> </B>
    <P>
      String versions of all (or) most functions that take C-style strings (e.g.
      filestream constructors)<B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=atoi>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Simple numeric access </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Bjarne Stroustrup<B><BR>
      <B>Paper:<A></A> </B> </B>
    </P>
    <B> </B>
    <P>
      Simple functions for extracting int and floating-point values out of a
      string<B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=richerstringinterface>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> A richer <TT>std::string</TT> interface </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Frank Yeh, John Medema, and others.<B><BR>
      <B>Paper:<A></A><A></A> </B> </B>
    </P>
    <B> </B>
    <P>
      Better member functions in string template class eg. trimming, upper/lower
      case conversion etc. Some specific suggestions:
    </P>
    <UL>
      <LI>
        Conversion between wstring and string
      <LI>
        Directly conversion between fundamental data types (int, char, char*,
        double etc.)
      <LI>
        Reference counting and "copy-on-write".
      <LI>
        Regular expression<B></B> <B> </B>
    </UL>
    <B> </B>
    <P>
      <B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=threads>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Threads </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Bill Kempf, Bjarne Stroustrup, Andrei
      Alexandrescu, others<B><BR>
      <B>Paper:<A></A> </B> </B>
    </P>
    <B> </B>
    <P>
      <B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=sockets>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Sockets </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester: </B>Bjarne Stroustrup<BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      <B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=unicode>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Explicit support for Unicode </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Matt Austern, Assaf Lavie<B><BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      Assaf Lavie adds: Text encoding libraries - all formats of Unicode and
      code page conversions, base64 (maybe through iostream manipulators), etc.
    </P>
  </DIV>
  <A></A><A></A>
  <DIV CLASS=wish ID=xml>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> An XML parser and generator library </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Bjarne Stroustrup<B><BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      <B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=constructivereal>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Constructive reals </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Bjarne Stroustrup, Hans Boehm<B><BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      "Infinite precision" reals.<B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=gui>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> GUI </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> </B>Bjarne Stroustrup, Michael Rasmussen, John
      Medema, others<B><BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      Some form of simple graphic/GUI library (possibly a simple interface to
      the simpler parts of larger libraries)—a recurent theme.
    </P>
    <P>
      Some thoughts on this from Michael Rasmussen:<BR>
      The main architecture resembles the idea behind Java's JDBC. E.g. the
      language/library provides a standard interface or set of interfaces and
      developers of graphics libraries does the actual implementation. If put
      into a design pattern terminology the standard interface is a factory
      hiding all implementation specific stuff from the programmer. The standard
      interface would specify features and their dependencies but otherwise
      leave implementation descessions to the developers of the graphics
      library.
    </P>
    <P>
      There are many advantages to this architecture of which I will point out
      the most important ones:
    </P>
    <UL>
      <LI>
        Portability: Write one GUI class and reuse it on any platform providing
        a C++ GUI standards compliant implementation.
      <LI>
        Simplicity: The C++ language does not need to maintain a binary code
        base on every available platform. All the language needs to maintain is
        a specification for the interface.
      <LI>
        Compatibility: If the architecture is chosen backwards compatibility can
        be maintained because the interface will be purely written in standard
        C++ and have no ties to the underlying platforms graphics specifications
        and/or hardware.
      <LI>
        Control: No graphics library will be able to extend or change the
        functionality of the GUI interface in the language. This means that the
        community will be in full control of the direction and development but
        at the same time the community will not in any way prevent developers of
        graphics libraries to go further. A core will be standards compliant and
        the extention will not be.
    </UL>
    <P>
      It is hard for me to point out some disadvantages but of course one is
      obvious: The success depends on adaptation from developers of graphics
      libraries.
    </P>
  </DIV>
  <DIV CLASS=wish ID=mmap>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      <B> Random access to files </B>
    </H3>
    <B> </B>
    <P CLASS=headers>
      <B> <B>Requester:</B> Bjarne Stroustrup, Chris Messer<BR>
      <B>Paper: </B> </B>
    </P>
    <B> </B>
    <P>
      A facility for random-access to files; maybe a form of random-access
      iterators for filestreams.
    </P>
    <P>
      One can totally facilitate this random-access by memory-mapping the
      desired file. Unfortunately, the API for file mapping is different between
      platforms. ( ie. mmap() vs. CreateFileMapping() ). I would find it
      extremely useful to have a standardized file-mapping API.<B> </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=rangechecking>
    <B> </B><HR STYLE="WIDTH: 100%; HEIGHT: 2px"> <B> </B>
    <H3>
      <B> Safe STL </B>
    </H3>
    <SPAN STYLE="FONT-WEIGHT: bold">Requester:</SPAN> Gary Powell<BR>
    <B>Paper: </B>
    <P>
    </P>
    <P>
      a range checked version of standard containers/iterators and algorithms<BR>
    </P>
    <A></A>
  </DIV>
  <DIV CLASS=wish ID=SIunits>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Filesystem access
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Bjarne Stroustrup, Beman Dawes<BR>
      <B>Paper: </B>
    </P>
    <P>
      a way of manipulating files that are part of a directory structure
    </P>
    <DIV CLASS=wish ID=process>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Process manipulation
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> unknown<BR>
        <B>Paper: </B>
      </P>
      <P>
        Process manipulation library—allows you to iterate processes running on
        the system and its threads, support forking, duping a process, killing
        etc.
      </P>
    </DIV>
    <DIV CLASS=wish ID=linearalgebra>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Linear algebra
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Bjarne Stroustrup, Tanguy Fautré, Sunil Palicha,
        Michael Hopkins<BR>
        <B>Paper: </B>
      </P>
      <P>
        a good linear algebra library (Matrices and vectors)
      </P>
      <BR>
      Michael Hopkins adds:<BR>
      <BLOCKQUOTE>My main plea is on a Linear Algebra library which is
      definitely needed for numeric work, to stop people having to implement it
      themselves and usually doing a poor or incomplete job – either in terms of
      efficiency or generality (or both).<BR>
      <BR>
      As well as the obvious requirements of easy interface to C &amp; Fortran
      math libraries, PLEASE make sure that vector/matrix/tensor access &amp;
      manipulation can be from 1..n with no loss of efficiency (or possibly with
      any arbitrary start and end, but at least 1..n) and not force it to be
      from 0..n-1.&nbsp; We do this in our own libraries by defining operator()
      thus:&nbsp; v( n ) -&gt; v[ n-1 ] ,&nbsp; M( n, m ) -&gt; M[n-1][m-1]
      etc.&nbsp; This could be described as Fortran style and is definitely more
      natural for math/stats work.&nbsp; Efficient methods for representing and
      iterating slices with guaranteed no copying would also be very useful.<BR>
      <BR>
      Iteration from 1..n is essential to tempt math &amp; stats people to use
      the library - maybe as converts from Fortran or other languages which use
      this more math-friendly syntax as a default.<BR>
      <BR>
      Ability to express sub-matrices, block matrices, projection/slices etc in
      a natural syntax.&nbsp; This is touched on in section 22.4 of BS’s book
      TC++PL using std::valarray and its’ related types which may be good
      candidates for implementing a standard linear algebra library. There are
      no guarantees that using these auxiliary types disallows copying though,
      and this suggests that a straightforward implementation could compromise
      runtime efficiency – see below.<BR>
      <BR>
      Runtime efficiency will be an important part of convincing math users to
      use the library.&nbsp; This will obviously have an impact on the simple
      iterators and slice/projection operators that are provided and how they
      are implemented.<BR>
      <BR>
      Operator overloading would clearly be useful for obvious cases ( *, /, +,
      -, ^ ), though many matrix and vector operations &amp; algorithms will be
      much better implemented by calls to BLAS, LAPACK etc libs optimised for
      the individual platform (e.g. ACML, MKL, ATLAS).&nbsp; Maybe these could
      be overloaded/specialised as necessary when optimised implementations are
      available?&nbsp; Some ideas are mentioned in TC++PL 22.4.7.<BR>
      <BR>
      boost::MultiArray and boost::uBLAS&nbsp; both look like promising work
      towards a standard linear algebra library facility though I have not used
      either myself so cannot comment on their efficiency or generality.&nbsp;
      Maybe the authors of these could be brought in on the design process? I
      suspect that heavy-duty template meta-programming like Blitz++ (and
      uBLAS?) would produce very long compile times though, and it is likely
      that linking to optimised C and Fortran libraries would be preferable in
      many cases – see above.<BR>
      <BR>
      Linear algebra types should be generic for fundamental math types (i.e.
      float, double, long double, int, unsigned int, long, unsigned long, long
      long, unsigned long long) but there may be an argument for not extending
      this to all types – so maybe typelists would be useful?<BR>
      <BR>
      There are many good ideas related to linear algebra types in Part III of
      Barton &amp; Nackman book “Scientific &amp; Engineering C++” (chapters 13,
      15, 18), though it’s possible that C++ language facilities and programming
      paradigms that take into account language strengths and weaknesses have
      moved on in some areas since then.<BR>
      <BR>
      Interfacing to C and Fortran libraries should be a ‘no-brainer’.&nbsp;
      This will probably mean:<BR>
      that all values in a linear algebra object must be stored contiguously<BR>
      providing a member function that returns a pointer to the first element<BR>
      <BR>
      boost::function is useful for generalising math operations.<BR>
      </BLOCKQUOTE>
    </DIV>
    <DIV CLASS=wish ID=virtualdestructors>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Virtual destructors for containers
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> David Miller<BR>
        <B>Paper: </B>
      </P>
      <P>
        Versions of the standard containers with virtual destructors
      </P>
    </DIV>
    <DIV CLASS=wish ID=movesemantics>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Move semantics
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Howard Hinnant<BR>
        <B>Paper: </B>
      </P>
      <P>
        Move semantics, which requires core and library support
      </P>
    </DIV>
    <DIV CLASS=wish ID=typesafeprintf>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        String formatting
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Gary Powell<BR>
        <B>Paper: </B>
      </P>
      <P>
        A string formatting library. (Aka, type safe printf) John Bates suggests
        that one way to improve on printf would be to have <I>explicit</I>
        parameter substitution via numbering, as opposed to the implicit
        ordering in printf. This would be similar to Java's MessageFormat object
        or Microsoft's FormatMessage API and would allow better
        internationalization support.
      </P>
      <BR>
      Dennis Lubert adds:<BR>
      Use
      <A HREF=http://www.boost.org/libs/format/index.html TITLE=boost.format>boost.format</A>
      like features for streams directly, or via some boost.format like helpers
      (for input as well as output). While C++ streams have the nice feature of
      beeing able to overload operator&lt;&lt; they lack of the feature of
      giving sanely output via some external data (format strings). boost.format
      is an existing practice that makes this available for output, it would be
      really nice to have this as input too,e.g. to specify input formats for
      configurable 3rd party program output. This would go along with Gary
      Powells string format wish.<BR>
    </DIV>
    <DIV CLASS=wish ID=dynamicany>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Runtime generic container
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Gary Powell<BR>
        <B>Paper: </B>
      </P>
      <P>
        A container to hold anything, like dynamic_any
      </P>
    </DIV>
    <DIV CLASS=wish ID=dates>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Date and time
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Gary Powell<BR>
        <B>Paper: </B>
      </P>
      <P>
        A date/time library, a date is not a duration! And an end to time_t.
      </P>
    </DIV>
    <DIV CLASS=wish ID=graphs>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Graph algorithms
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Gary Powell<BR>
        <B>Paper: </B>
      </P>
      <P>
        a graph library, aka boost/graph (supplements std containers)
      </P>
    </DIV>
    <DIV CLASS=wish ID=quaternions>
      <H3>
      </H3>
      <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
      <H3>
        Quaternions and octonions
      </H3>
      <P CLASS=headers>
        <B>Requester:</B> Gary Powell<BR>
        <B>Paper: </B>
      </P>
      <P>
        math/octonion &amp; math/quaterion's (used by game designers for 3d
        math.)
      </P>
    </DIV>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Units
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Gary Powell, Walter Brown, Andy Little<BR>
      <B>Paper: </B>
    </P>
    <P>
      a SI/Units library. ( e = m c<SUP>2</SUP>, and end to the mars lander
      crashes.)
    </P>
    <P>
      One example of work in this area is Andy Little's
      <A HREF=http://www.servocomm.freeserve.co.uk/Cpp/physical_quantity/index.html>pqs
      library</A>, which addresses physical quantities as well as units.
    </P>
  </DIV>
  <DIV CLASS=wish ID=xalgo>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      More STL algorithms
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Matt Austern<BR>
      <B>Paper: </B>
    </P>
    <P>
      New STL algorithms: copy_if, is_sorted, versions of the uninitialized_*
      algorithms that take allocator arguments.
    </P>
  </DIV>
  <DIV CLASS=wish ID=webservices>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Web services
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Jonathan Schilling<BR>
      <B>Paper: </B>
    </P>
    <P>
      A SOAP- and XML-based web services binding to the standard library. There
      would also need to be some kind of metalanguage/directives mechanism for
      marking within the C++ source, which classes and functions are being
      exposed as web services.
    </P>
  </DIV>
  <DIV CLASS=wish ID=morespecialfunctions>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      More special functions
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Paul Bristow<BR>
      <B>Paper: </B> N1668 = 04-0108, "A Proposal to add Mathematical Functions
      for Statistics to the C++ Standard Library", Paul Bristow
    </P>
    <P>
      More math functions for statistics: Student's <I>t</I> function,
      Kolmogorov statistic, incomplete beta function, digamma function, and so
      on.
    </P>
  </DIV>
  <DIV CLASS=wish ID=himult>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Full-width integer operations
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Matt Austern<BR>
      <B>Paper: </B>
    </P>
    <P>
      A mechanism for accessing integer operations that every processor has:
      addition with carry, full-width multiplication, and division with
      remainder and quotient. The signatures might look something like this: <TT>pair&lt;UInt, bool&gt; add(UInt, UInt);</TT>,
      <TT>pair&lt;UInt, UInt&gt; mult(UInt, UInt);</TT>, <TT>pair&lt;UInt, UInt&gt; div(UInt, UInt);</TT>. We would probably want overloads for <TT>unsigned int</TT>, <TT>unsigned long</TT>, <TT>unsigned long long</TT> (assuming
      it's added to the core language), and maybe <TT>unsigned char</TT>.
    </P>
    <BR>
    <P>
      Nick Krempel adds:
    </P>
    <P>
      Firstly, I wanted to point out that addition with carry is already
      possible in a reasonably natural way as follows:<BR>
    </P>
    <BLOCKQUOTE><SPAN STYLE="FONT-FAMILY: Courier New">unsigned int a, b,
    c;</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">// a and b are
    inputs</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">c = a +
    b;</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">if (c &lt; a) //
    carry</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">else // no carry</SPAN><BR>
    </BLOCKQUOTE>
    <P>
      This seems slightly easier to work with than a pair object, but I can see
      why you may want the pair object version for uniformity.<BR>
      &nbsp;<BR>
      Secondly, and more importantly, I wanted to emphasize the importance of a
      2-by-1 division.<BR>
      &nbsp;<BR>
      That is, a division taking a double-precision number (which could be 2
      separate ‘UInt’s of the relevant type) and a single-precision divisor and
      returns a single-precision result. An exception can be thrown if the
      result doesn’t fit in single precision. Another version can also return a
      single-precision remainder.<BR>
      &nbsp;<BR>
      This operation is important for implementing multiprecision arithmetic
      (for example a divide n-by-1 is easily implemented in terms of it), and it
      is available as a single assembler instruction on Intel processors. It is
      a natural inverse to the 1x1-&gt;2 full-width multiplication you propose.<BR>
      &nbsp;<BR>
      Of course, it can be implemented in terms of usual (C++) arithmetic
      operations, but this requires at least as much code as implementing your
      proposed full multiplication in terms of the usual C++ multiplication (at
      least 3 multiplications and some bit shifting), and of course will be a
      number of times slower. So it seems in line with your proposal to include
      this operation too.<BR>
    </P>
  </DIV>
  <DIV CLASS=wish ID=database>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Database support
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Rüdiger Brünner, John Medema, Eduardo Yánez<BR>
      <B>Paper: </B>
    </P>
    <P>
      Generic database support; STL-based recordset operations
    </P>
  </DIV>
  <DIV CLASS=wish ID=serialization>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Serialization
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Rüdiger Brünner, Raffaele Mancuso,
      <SPAN ID=_pro_anubhav.hanjura@convergys.com>Anubhav Hanjura, </SPAN>others<BR>
      <B>Paper: </B>
    </P>
    <P>
      Library for binary object serialization/deserialization including object
      factory, versioning support, support for native datatypes and Standard
      Library classes (std::basic_string, STL containers, std::complex, etc.)
    </P>
    <BR>
    <P>
      <SPAN ID=_pro_anubhav.hanjura@convergys.com>Anubhav Hanjura adds:
      </SPAN><FONT FACE=sans-serif SIZE=2>I would want C++ to support
      serialization and deserialization of complex data structures (may be based
      on the STL) completely, so that data streams can be exchanged without
      bothering about endianness or encoding/decoding specifics.</FONT>
    </P>
  </DIV>
  <DIV CLASS=wish ID=fixedpoint>
    <H3>
    </H3>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Fixed-point arithmetic
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Rüdiger Brünner<BR>
      <B>Paper: </B>
    </P>
    <P>
      Fixed-point arithmetic library and currency class based upon it
    </P>
  </DIV>
  <DIV CLASS=wish ID=patterns>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Patterns
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Rüdiger Brünner, Assaf Lavie<BR>
      <B>Paper: </B>
    </P>
    <P>
      Singleton template (like in the Loki library) and probably also generic
      implementations of other common patterns. Assaf Lavie adds a request for
      machine-wide singleton classes.
    </P>
  </DIV>
  <DIV CLASS=wish ID=intervalarithmetic>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Interval arithmetic
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Sylvain Pion<BR>
      <B>Paper: </B>
    </P>
    <P>
      The Sun compiler provides a built-in type for interval arithmetic, and
      Boost and CGAL have interval classes. There are many other implementations
      elsewhere.
    </P>
  </DIV>
  <DIV CLASS=wish ID=virtualconstructor>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Class factory implementation
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Alisdair Meredith<BR>
      <B>Paper:</B>
    </P>
    <P>
      One item I would like to add to the LWG wish list if a 'class factory' or
      'virtual constructor' implementation, again inspired by Loki. I have been
      wrestling with several points of the design space, trying to find the best
      balance. Was hoping to propose something for TR2 but there is one issue
      that really needs core (i.e. Evolution) support before we can have a truly
      satisfying interface, and that is the ability to work with any constructor
      rather than just the default.
    </P>
    <P>
      A mix of perfect forwarding and var-arg template parameters will get us
      some way there, but I'm still not sure it is enough.
    </P>
    <P>
      Another issue not immediately tied in is the progress on dynamic
      libraries, as class factories often lie at the heart of plug-in schemes.
    </P>
    <P>
      Beyond that it is a matter of defining the optimal interface. The Loki
      version is quite policy driven eg. for return type. Do we want to allow a
      variety of returns, or fix on tr1::shared_ptr, or auto_pr (or even
      move_ptr if it arrives)?
    </P>
  </DIV>
  <DIV CLASS=wish ID=allocators>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Full support for user-defined memory models
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Dmitriy Morozov and others<BR>
      <B>Paper: </B>
    </P>
    <P>
      The standard's allocator machinery, in principle, allows users to define
      allocators with alternate memory models. (The original motivation was
      MS-DOS's "near" and "far" memory models.) Allocators have <TT>reference</TT> and <TT>pointer</TT>
      typedefs. However, this support is seriously limited. First, the current
      standard doesn't allow any freedom for <TT>Alloc::reference</TT>: it is required to be <TT>T&amp;</TT>.
      Second, 20.1.5/4-5 says that standard library implementations are allowed
      to ignore an allocator's memory model typedefs and assume that all
      allocators use the usual memory model.
    </P>
    <P>
      These restrictions should be removed. This may require some core language
      changes. It may also require writing out requirements that an alternate
      memory model must satisfy.
    </P>
  </DIV>
  <DIV CLASS=wish ID=doxygen>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Documentation mechanism
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Diego Bragato<BR>
      <B>Paper: </B>
    </P>
    <P>
      A standardized documentation facility (e.g. doxygen)
    </P>
  </DIV>
  <DIV CLASS=wish ID=metadata>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Metadata support
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Diego Bragato<BR>
      <B>Paper: </B>
    </P>
    <P>
      A metadata language support (e.g. xdoclet,jdk1.5)
    </P>
  </DIV>
  <DIV CLASS=wish ID=UML>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Design paradigms
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Diego Bragato<BR>
      <B>Paper: </B>
    </P>
    <P>
      Support for reversibility from the implementation to a "set of" design
      paradigms (e.g. UML and eiffel). I do feel that this would be a strong
      innovation. This feature can be nicely integrated with graph support,
      documentation, metadata, and even the graphical facilities
    </P>
  </DIV>
  <DIV CLASS=wish ID=contract>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Design by contract
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Diego Bragato<BR>
      <B>Paper: </B>
    </P>
    <P>
      Support for the design by contract method, including standardized support
      for testing available from the asserts in the contracts.
    </P>
  </DIV>
  <DIV CLASS=wish ID=aspects>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Aspects
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Diego Bragato<BR>
      <B>Paper: </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=webservicecontainer>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Web service container
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Diego Bragato<BR>
      <B>Paper: </B>
    </P>
    <P>
      Specification for a web service container, taking into account also
      authentication
    </P>
  </DIV>
  <DIV CLASS=wish ID=mapreserve>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      map and reserve
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Liran Shaul<BR>
      <B>Paper: </B>
    </P>
    <P>
      Why doesn't the std::map class offer a method reserve that will allocate
      memory ahead of time, like the vector::reserve function?
    </P>
    <P>
      I understand that this function won't be able to be as efficient as the
      vector/list matching function, However allocating all the memory (or at
      least most of it) In advance has 2 major advantages that I can think of:
    </P>
    <OL>
      <LI>
        one big call to the new operator is probably better then many small
        memory allocations
      <LI>
        In case that there is not enough memory, it is probably better to know
        about it In advance then starting to enter items into the map, just to
        discover later that there is not enough memory in the system to hold a
        map that big.
    </OL>
  </DIV>
  <DIV CLASS=wish ID=atomicity>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Atomic operations
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Jeremy Jurksztowicz, James Buchanan, Lubos Dolezel, and
      others.<BR>
      <B>Paper: </B>
    </P>
    <P>
      I was just going over the wishlist for the C++ standard and have another
      suggestion. As lock free programming comes more and more into mainstream,
      why not add an atomic type to C++? Something like 'volatile word',
      'atomic&lt;T&gt;' or just make it a requirement that all accesses to
      volatile ints are atomic, for most common platforms it already is. This
      would make portable FIFO, and other lock free structure implementations
      trivial. Alternatively you could add a std::compare_and_swap function.
    </P>
    <P>
      James Buchanan adds a request for mutexes, semaphores, and spinlocks. This
      would be enough for low level system programming on SMP machines.
    </P>
    <P>
      Lubos Dolezel adds: Something like std::mutex would be great. Just a
      simple multiplatform class for mutexes with methods like lock(), unlock()
      and trylock() would simplify many projects.
    </P>
  </DIV>
  <DIV CLASS=wish ID=algoc>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Container-based algorithms
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Kirk Korver<BR>
      <B>Paper: </B>
    </P>
    <P>
      One of the annoyances I have with using the STL is it's implementation of
      std::for_each(). I think this algorithm is a great idea, and passing in
      the start and end ranges are nice for flexibility. But I ask you, how many
      times have you used for_each on EVERY ELEMENT in the collection? I would
      wager that it is upwards of 90%. Why do so much typing for something we do
      often?
    </P>
    <P>
      I propose: The addition of the algorithm for_all, which is a replacement
      to for_each, where the functor is to be applied to ALL elements in the
      collection.
    </P>
    <P>
      Here is the actual implementation I have in my code.
    </P>
    <PRE>namespace std<BR>{<BR>    // Author &amp; Date:   Kirk Korver     03 Jun 2004<BR>    // Purpose: wrap the std::for_each function to apply the functor to ALL entries<BR>    // Inputs:<BR>    //  c - the container we care about<BR>    //  f - the function or functor we want to apply<BR>    template &lt;class Container, typename Functor&gt; inline<BR>    Functor for_all(Container  &amp; c, Functor &amp; f)<BR>    {<BR>        return std::for_each(c.begin(), c.end(), f);<BR>    }<BR>};<BR></PRE>
  </DIV>
  <DIV CLASS=wish ID=containerthreads>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Control over containers' threading model
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Greg Osgood<BR>
      <B>Paper: </B>
    </P>
    <P>
      There is one feature that I would like to see added to the STL: the
      ability to specify the threading model for collections. In most
      implementations the threading model is defined at the project level. There
      are some situations in which accessing a collection if very critical to
      performance of the application. If the threading model is single threaded
      then the performance will be very close to the same as using arrays.
      However, if the threading model is multithread then the performance may
      suffer greatly. This seems pretty obvious to me, but if you have any
      questions or need clarification let me know.
    </P>
  </DIV>
  <DIV CLASS=wish ID=shrinktofit>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      More convenient way of deallocating vector memory
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Tyler Doubrava, Chris Messer<BR>
      <B>Paper: </B>
    </P>
    <P>
      It would be great if std::vector&lt;&gt; had an intuitive way to
      deallocate its memory. You can do so by calling the member function
      swap(), providing an empty instance of the same type. Most people, I
      believe, would have intuitively expected the clear() member function to do
      so.
    </P>
    <P>
      I suggest adding a new member function, dealloc() which would call clear,
      and free the vector's memory.
    </P>
    <P>
      Further comment from Chris Messer:<BR>
      I believe it is important to maintain the functional difference between
      clearing a list and freeing it. If one intends to re-fill the list, then
      clearing saves the performance hassle of re-allocating, so I don't think
      that freeing memory in clear() is a good idea. It would be nice to have a
      member function tidy() that wasn't related to clear(), but that freed all
      of the vector's unused capacity. (At least one implementation already
      provides _Tidy as a nonstandard extension.)
    </P>
  </DIV>
  <DIV CLASS=wish ID=lexertl>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Lexical analysis and parsing
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Benjamin Hanson<BR>
      <B>Paper: </B> <A HREF=http://www.benhanson.net/lexertl.html>lexertl: The
      Modular Lexical Analyser Generator</A>
    </P>
    <P>
      I would like to see a lexical analyser generator library (and even maybe
      some kind of yacc library) added to std::tr2. Dave Handley and myself are
      currently developing a lexical analyser generator 'lexertl' which can be
      viewed at
      <A HREF=http://www.benhanson.net/lexertl.html>http://www.benhanson.net/lexertl.html</A>.
    </P>
    <P>
      James Buchanan adds:
    </P>
    <BLOCKQUOTE> Spirit is very nice, but is quite hackish. I think it's better
    to have some kind of template where you can choose the algorithm
    (LL(k)/resursive descent, GLR, LALR, LR(k)) and make the lexical analysis
    and parsing framework understand EBNF as a standard way for feeding in a
    CFG. Also, there should be additional types like symbol tables and an AST
    type. </BLOCKQUOTE>
  </DIV>
  <DIV CLASS=wish ID=graphics>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Graphics library
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> James Buchanan<BR>
      <B>Paper: </B>
    </P>
    <P>
      Some kind of standard interface for dealing with graphics primitives
      (hooks into X or ncurses/dialog on Unix systems, or optionally SVGAlib on
      Linux, Win32 on Windows systems, whatever on Mac).
    </P>
    <P>
      Also multimedia: A standard interface to the audio and video facilities on
      a platform.
    </P>
  </DIV>
  <DIV CLASS=wish ID=trees>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Trees
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> James Buchanan<BR>
      <B>Paper: </B>
    </P>
    <P>
      Binary trees, splay trees, Red-Black trees, B trees, B+ trees, dancing
      trees (those used in Hans Reiser's Reiser File System).
    </P>
  </DIV>
  <DIV CLASS=wish ID=compression>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Data compression
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> James Buchanan<BR>
      <B>Paper: </B>
    </P>
  </DIV>
  <DIV CLASS=wish ID=embedded>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Better support for embedded programming
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> James Buchanan<BR>
      <B>Paper: </B>
    </P>
    <P>
      This would be separate from the Standard C++ library proper, and become a
      second standard library. There is a draft of C for embedded systems that
      the embedded C++ stdlib could make use of as a starting point. The
      embedded stdlib would need to have interfaces for access to low-level
      system I/O (inport_b, outport_b and friends), etc.
    </P>
  </DIV>
  <DIV CLASS=wish ID=mapiterators>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Specialized iterators and/or algorithms for map iterators
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Zach Laine<BR>
      <B>Paper: </B>
    </P>
    <P>
      The lack of uniformity between std::map iterators and other container's
      iterators could be partially addressed by providing "*_value" versions of
      std::for_each, std::accumulate, etc.. These versions would be specialized
      for iterators whose value_types are std::pairs, and would operate only on
      the .second member thereof, while still operating as before on iterators
      with non-std::pair value_types. Alternately, this could be accomplished by
      providing a new iterator that wraps a given iterator, and returns the
      wrapped iterator's value_type's .second member when dereferenced, if
      appropriate.
    </P>
    <P>
      This lack of uniformity could be fully addressed by acknowledging that
      std::map is a bit different than the other containers, and creating a
      custom iterator type for its use. This new iterator type would still
      provide access to the key associated with its associated element, through
      a method called key_value() or similar, but would access its element's
      mapped value when dereferenced, and would access its element's mapped
      value's members using operator-&gt;().
    </P>
  </DIV>
  <DIV CLASS=wish ID=unicodefilenames>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Open Unicode-named files
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Assaf Lavie<BR>
      <B>Paper: </B>
    </P>
    <P>
      To be able to open Unicode-named files using fstream (i.e. not just a
      string c'tor but also a wstring c'tor).
    </P>
  </DIV>
  <DIV CLASS=wish ID=tchar>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Pervasive TCHAR support
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Assaf Lavie<BR>
      <B>Paper: </B>
    </P>
    <P>
      i.e. standard basic_string&lt;tchar&gt; where tchar compiles to either
      char or wchar_t
    </P>
  </DIV>
  <DIV CLASS=wish ID=network>
    <H3>
    </H3>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Network programming
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Assaf Lavie<BR>
      <B>Paper: </B>
    </P>
    <P>
      From Assaf Lavie:
    </P>
    <BLOCKQUOTE>I wish it was as easy to do web-stuff in C++ as it is in, say,
    perl. Classes for HTTP/FTP/HTTPS/XML/HTML/</BLOCKQUOTE>
    <P>
      From John Medema:
    </P>
    <BLOCKQUOTE> A unified socket/stream interface. Perhaps
    <PRE>nstream nsck( "www.google.com:80", "#" )<BR></PRE>
    where "#" is a delimiter string for string parsing (i.e. the stream contains
    "1#2#3#4.4#5", and repeated calls nsck &gt;&gt; myString would yield
    myString values of 1, 2, 3, 4.4, and 5). </BLOCKQUOTE>
  </DIV>
  <DIV CLASS=wish ID=lambda>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      λ expressions
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Assaf Lavie<BR>
      <B>Paper: </B>
    </P>
    <P>
      lambda expressions - std::for_each is hardly useful without them.
    </P>
  </DIV>
  <DIV CLASS=wish ID=ccompat>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Better C compatibility
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> John Medema<BR>
      <B>Paper: </B>
    </P>
    <P>
      Wrapper libraries for common C functions. This would be largely
      unnecessary if we could get a richer std::string interface with
      conversions to and from C data types, but there are a great many socket
      functions that need dynamically allocated pointers.
    </P>
  </DIV>
  <DIV CLASS=wish ID=binaryfind>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      binary_find
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Greg Osgood<BR>
      <B>Paper: </B>
    </P>
    <P>
      I would like to see a binary_find function in STL algorithm which would
      work just like binary_search except instead of returning a bool indicating
      whether or not the item was found, would return an iterator to the object
      if it is found and the end of the collection if it is not. Just like
      binary_search, there should be two versions one which takes a predicate.
      The function signature could be as follows:
    </P>
    <PRE>  template&lt;class ForwardIterator, class Type&gt;<BR>     ForwardIterator binary_find(<BR>        ForwardIterator _First, <BR>        ForwardIterator _Last,<BR>        const Type&amp; _Val<BR>     );<BR>  template&lt;class ForwardIterator, class Type, class BinaryPredicate&gt;<BR>     ForwardIterator binary_find(<BR>        ForwardIterator _First, <BR>        ForwardIterator _Last,<BR>        const Type&amp; _Val, <BR>        BinaryPredicate _Comp<BR>     );<BR> </PRE>
    <P>
      (This would just be lower_bound followed by an equality check, but it
      might still be useful.)
    </P>
  </DIV>
  <DIV CLASS=wish ID=intrusivecontainers>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Intrusive containers
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Ravi Menon<BR>
      <B>Paper: </B> <A HREF=http://people.freenet.de/turtle++/intrusive.html>A
      candidate for a boost version of intrusive containers</A>
    </P>
    <P>
      We have observed performance problems with std stl containers (it is used
      at certain areas in our code), and sticking with old C code (space and
      time efficient) is too cumbersome.
    </P>
    <P>
      Without getting into ugly details, one main issue we see with stl
      containers like map and hash_map is the 'extra allocation' required for
      the node - _Hashtable_node for hash_map and _Rb_tree_node for map. Even if
      we are storing pointers to objects (for key and value) to avoid copy ctor
      overheads for the pair, for MT systems with mutex overhead, it still is an
      issue.
    </P>
    <P>
      Although I am a big fan of stl containers, this is one criticism I can't
      overcome from folks who are more used to old C style intrusive
      implementations (with all that unsafe casts to void* etc..).
    </P>
    <P>
      No amount of positive arguments in favor like type safety, inlining (as
      opposed to fn pointers used for hash comparators and hash functions),
      readability, s/w maintenance etc.. can overcome the bias in favor of
      measurable (and significant) performance gains with intrusive lists.
    </P>
  </DIV>
  <DIV CLASS=wish ID=hashpolicy>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Better control over hash policy
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Ravi Menon<BR>
      <B>Paper: </B>
    </P>
    <P>
      It would be useful to have some provision (a template argument?) to supply
      an alternative hash table used for unordered associative containers. E.g.
      power of 2 size hash table to avoid mod (%) arithmetic, and get to the
      bucket via bit-wise '&amp;' - i.e. bucket = hash &amp; (size - 1). I can
      think of some designs and willing to contribute if there is an interest.
    </P>
  </DIV>
  <DIV CLASS=wish ID=exceptionclone>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      clone() for standard exceptions
    </H3>
    <P CLASS=headers>
      <B>Requester:</B> Jeroen Vermeulen<BR>
      <B>Paper:</B>
      <A HREF=http://www.xs4all.nl/%7Ejtv/proj-c++wishlist.html#cloningexceptions>Cloning
      Exceptions</A>
    </P>
    <P>
      We need a way to be able to create copies of exception objects, without
      full static type information. This helps parallelism because it allows us
      to write frameworks that perform multiple tasks independently of one
      another, and gather up their successes and failures for later processing.
      Just catch any exception coming out of each individual task, add it to a
      container of results, and proceed to the next independent task.
    </P>
    <P>
      The <TT>std::exception</TT> hierarchy already has a vtable, so this is no great loss in terms
      of performance. Now, every concrete class derived from <TT>std::exception</TT> would hopefully
      implement this function, always returning a copy of itself as a <TT>std::auto_ptr&lt;std::exception&gt;</TT> to
      avoid changing the return type--but dynamically it would always point to
      an exception of the right type. Programmers implementing exception classes
      of their own would be called upon to do the same.
    </P>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Linked containers
    </H3>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Requester</SPAN><SPAN STYLE="FONT-WEIGHT: bold">:</SPAN>
      Fernando Lagos
    </P>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Paper:</SPAN>
      <A HREF=http://www.codeproject.com/vcpp/stl/linked_map.asp TITLE=http://www.codeproject.com/vcpp/stl/linked_map.asp>http://www.codeproject.com/vcpp/stl/linked_map.asp</A>
    </P>
    <P>
      A family of adaptors/containers to make the standard associative
      containers know the insertion/get/deletetion order. An example can be seen
      at http://www.codeproject.com/vcpp/stl/linked_map.asp<BR>
    </P>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Templated copy constructors for containers
    </H3>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Requester:</SPAN> George Faraj<BR>
    </P>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Paper:</SPAN>
    </P>
    I'm writing to propose something to the library wish list. I haven't found
    this in the active issues list.<BR>
    <BR>
    All containers should provide a templated copy constructor like that in
    boost::shared_ptr. This would allow to construct a container out of another
    container with different but convertible elements.<BR>
    <BLOCKQUOTE><SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;ConvertibleToInt&gt;
    v1;</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">...</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;int&gt; v2 =
    v1;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //
    error</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;int&gt; v2(v1.begin(),
    v2.end());&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //
    fine</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;std::vector&lt;ConvertibleToInt&gt;
    &gt; v3; </SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;std::vector&lt;int&gt;
    &gt; v4 = v3;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //
    error</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;std::vector&lt;int&gt;
    &gt; v5(v3.begin(), v3.end());&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //
    error</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">// fine but overly
    complicated</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;std::vector&lt;int&gt;
    &gt; v6; </SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;std::vector&lt;ConvertibleToInt&gt;
    &gt;::iterator it, end =
    v3.end();</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">for (it = v3.begin(); it != end;
    ++it)</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">&nbsp;&nbsp;&nbsp;&nbsp;
    v6.push_back(std::vector&lt;int&gt;(it-&gt;begin(),
    it-&gt;end()));</SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">// proposed syntax
    </SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">std::vector&lt;std::vector&lt;int&gt;
    &gt; v7 = v3;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // simple and
    intuitive<A></A></SPAN><BR>
    </BLOCKQUOTE><BR>
    Change:<BR>
    <BLOCKQUOTE><SPAN STYLE="FONT-FAMILY: Courier New">vector(vector&lt;T,
    Allocator&gt; const&amp;);</SPAN><BR>
    </BLOCKQUOTE><BR>
    To:<BR>
    <BLOCKQUOTE><SPAN STYLE="FONT-FAMILY: Courier New">template &lt;typename Y,
    typename AllocatorY&gt; </SPAN><BR STYLE="FONT-FAMILY: Courier New">
    <SPAN STYLE="FONT-FAMILY: Courier New">vector(vector&lt;Y, AllocatorY&gt;
    const&amp;);</SPAN><BR>
    </BLOCKQUOTE><BR>
    and so on for all containers.<BR>
    <BR>
    I don't forsee any impacts on already correctly written code, while
    promoting simple, readable code.<BR>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Templatized index type for indexed containers
    </H3>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Requester:</SPAN> Andy Jewell<BR>
    </P>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Paper:</SPAN>
    </P>
    <P>
      How about an additional template parameter for vector and bitset and such,
      that determines the index type, i.e. the type of the parameter to
      operator[], or perhaps more generally the size_type.<BR>
      <BR>
      Common uses would include enumerated types, or one the many abstractions
      to make integers into separate types.<BR>
      <BR>
      The only effect of this parameter would be to cause a compile time error
      if the wrong type is used.<BR>
      <BR>
      One could certainly wrap the existing classes to get this effect, which
      many people do, but it seems a waste of effort.<BR>
    </P>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Choose the underlying tree type of a
      std::map<SPAN STYLE="FONT-WEIGHT: bold"><BR>
      </SPAN>
    </H3>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Requester: </SPAN>Dennis Lubert
    </P>
    <SPAN STYLE="FONT-WEIGHT: bold">Paper:<BR>
    </SPAN>
    <P>
      Possibility to choose the underlying tree type of a std::map (probably via
      template parameter, of course std::set and the multi variants too). This
      probably goes together with the wish of additional tree types by James
      Buchanan (I would like to see a AVL Tree implementation there too). The
      main reason here is, that most std::map implementations use an rb tree
      implementation. While this is quite ok in most times, it can get very
      unbalanced if fed with badly ordered (sorted) data, which especially comes
      when copying maps (seems mostly done by inserting in-order).<A></A><BR>
    </P>
    <P>
      <BR>
    </P>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Boost.assign<SPAN STYLE="FONT-WEIGHT: bold"><BR>
      </SPAN>
    </H3>
    <P>
      <SPAN STYLE="FONT-WEIGHT: bold">Requester: </SPAN>Dennis Lubert
    </P>
    <SPAN STYLE="FONT-WEIGHT: bold">Paper:
    </SPAN><A HREF=http://www.boost.org/libs/assign/doc/index.html TITLE=http://www.boost.org/libs/assign/doc/index.html>http://www.boost.org/libs/assign/doc/index.html</A>
    <SPAN STYLE="FONT-WEIGHT: bold"> </SPAN>
    <P>
      One thing that I noted is especially handy for C++ newbies, is the
      boost::assign family of functions that allows a very intuitive handling of
      container input. I think most parts of those functions would be very good
      to have in C++.<BR>
    </P>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <H3>
      Boost finite state machines<A></A>
    </H3>
    <P>
      <FONT SIZE=2><SPAN STYLE="FONT-WEIGHT: bold">Requester:</SPAN> Oliver
      Kowalke</FONT>
    </P>
    <P>
      <FONT SIZE=2><SPAN STYLE="FONT-WEIGHT: bold">Paper:
      </SPAN></FONT><A HREF=http://boost-sandbox.sourceforge.net/libs/statechart/doc/index.html TITLE=http://boost-sandbox.sourceforge.net/libs/statechart/doc/index.html>http://boost-sandbox.sourceforge.net/libs/statechart/doc/index.html</A><BR>
    </P>
    <P>
      I would suggest boost::statechart library which allows the implementation
      of finite state machines over templates. It follows the UML-statechart
      notation. It will be included into boost-1.34. I'm using it and find it
      very impressive.<A></A>
    </P>
    <HR STYLE="WIDTH: 100%; HEIGHT: 2px">
    <P>
      <FONT SIZE=2><SPAN STYLE="FONT-WEIGHT: bold"></SPAN><SPAN STYLE="FONT-WEIGHT: bold"></SPAN><SPAN STYLE="FONT-STYLE: italic">Please
      send additions to this list to
      </SPAN><A HREF=http://lafstern.org/matt/ STYLE="FONT-STYLE: italic">Matt
      Austern</A><SPAN STYLE="FONT-STYLE: italic">, </SPAN><TT><SPAN STYLE="FONT-STYLE: italic">matt @ lafstern.org</SPAN></TT></FONT>
    </P>
  </DIV>
  <A></A> <ADDRESS> </ADDRESS>
</DIV></body>
</html>