<html>
<head>
<title>C++0x Standard Library wishlist</title>
</head>

<body
<font face="Arial, Helvetica, sans-serif">

<pre>
Doc. no.: N1901=05-0161
Date:     2005-10-14
Project:  Programming Language C++
Reply to: Matt Austern &lt;austern@google.com>
</pre>


<h1>C++0x Standard Library wishlist (revision 5)</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.
</p>

<p>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>

<h2>Categories</h2>

<p>Most of the entries in the wish list fall into a small number of
  general categories:</p>
<ul>
<li><b>System</b>: Things that can't be done portably in standard C++, such as
  filesystem access, sockets, database access, and persistence.</li>
<li><b>Numerics</b>: Numerical computation</li>
<li><b>Usability</b>: Usability improvements, particularly for novices.</li>
<li><b>Algorithms</b>: Algorithms and data structures</li>
</ul>

<!-- -------------------------------------------------- -->
<h2>The wish list</h2>

<hr />
<h3>Formatted container output</h3>
<p>
<b>Requester:</b> Dave Abrahams
<br />
<b>Paper: </b>
</p>
<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.</p>

<hr />
<h3>Infinite-precision integer arithmetic</h3>
<p>
<b>Requester:</b> Maarten Kronenburg, Bjarne Stroustrup, Matt
Austern, others 
<br />
<b>Paper:</b> N1718, "A Proposal to add the Infinite Precision
Integer and Rational to the C++ Standard Library", M. J. Kronenburg.
</p>

<hr />
<h3>Uniform use of std::string</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup
<br />
<b>Paper: </b>
</p>
<p>
String versions of all (or) most functions that take C-style
strings (e.g.  filestream constructors)
</p>

<hr />
<h3>Simple numeric access</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup
<br />
<b>Paper: </b>
</p>
<p>
Simple functions for extracting int and floating-point values out
of a string
</p>

<hr />
<h3>A richer <tt>std::string</tt> interface</h3>
<p>
<b>Requester:</b> Frank Yeh, John Medema, and others.
<br />
<b>Paper: </b>
</p>
<p>
Better member functions in string template class eg. trimming,
upper/lower case conversion etc.  Some specific suggestions:
<ul>
<li>Conversion between wstring and string</li>
<li>Directly conversion between fundamental data types (int, char,
    char*, double etc.)</li>
<li>Reference counting and "copy-on-write".</li>
<li>Regular expression</li>
</ul>
</p>

<hr />
<h3>Threads</h3>
<p>
<b>Requester:</b> Bill Kempf, Bjarne Stroustrup, Andrei Alexandrescu, others
<br />
<b>Paper: </b>
</p>
<p>
</p>

<hr />
<h3>Sockets</h3>
<p>
<b>Requester:</b>Bjarne Stroustrup
<br />
<b>Paper: </b>
</p>
<p>
</p>

<hr />
<h3>Explicit support for Unicode</h3>
<p>
<b>Requester:</b> Matt Austern, Assaf Lavie
<br />
<b>Paper: </b>
</p>
<p>
Assaf Lavie adds: Text encoding libraries - all formats of Unicode and
code page conversions, base64 (maybe through  iostream manipulators),
etc.
</p>

<hr />
<h3>An XML parser and generator library</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup
<br />
<b>Paper: </b>
</p>
<p>
</p>

<hr />
<h3>Constructive reals</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup, Hans Boehm
<br />
<b>Paper: </b>
</p>
<p>
"Infinite precision" reals.
</p>

<hr />
<h3>GUI</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup, John Medema, others
<br />
<b>Paper: </b>
</p>
<p>
Some form of simple graphic/GUI library (possibly a simple
interface to the simpler parts of larger libraries)&mdash;a recurent
theme.
</p>

<hr />
<h3>Random access to files</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup
<br />
<b>Paper: </b>
</p>
<p>
a facility for random-access to files; maybe a form of random-access 
iterators for filestreams
</p>

<hr />
<h3>Safe STL</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup
<br />
<b>Paper: </b>
</p>
<p>
a range checked version of standard containers/iterators and
algorithms
</p>

<hr />
<h3>Filesystem access</h3>
<p>
<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>

<hr />
<h3>Process manipulation</h3>
<p>
<b>Requester:</b> unknown
<br />
<b>Paper: </b>
</p>
<p>
Process manipulation library&mdash;allows you to iterate processes running
on the system and its threads, support forking, duping a process, killing etc. 
</p>

<hr />
<h3>Linear algebra</h3>
<p>
<b>Requester:</b> Bjarne Stroustrup, Tanguy Fautr&eacute;, Sunil Palicha
<br />
<b>Paper: </b>
</p>
<p>
a good linear algebra library (Matrices and vectors)
</p>

<hr />
<h3>Virtual destructors for containers</h3>
<p>
<b>Requester:</b> David Miller
<br />
<b>Paper: </b>
</p>
<p>
Versions of the standard containers with virtual destructors
</p>

<hr />
<h3>Move semantics</h3>
<p>
<b>Requester:</b> Howard Hinnant
<br />
<b>Paper: </b>
</p>
<p>
Move semantics, which requires core and library support
</p>

<hr />
<h3>String formatting</h3>
<p>
<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>

<hr />
<h3>Runtime generic container</h3>
<p>
<b>Requester:</b> Gary Powell
<br />
<b>Paper: </b>
</p>
<p>
A container to hold anything, like dynamic_any
</p>

<hr />
<h3>Date and time</h3>
<p>
<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>

<hr />
<h3>Graph algorithms</h3>
<p>
<b>Requester:</b> Gary Powell
<br />
<b>Paper: </b>
</p>
<p>
a graph library, aka boost/graph (supplements std containers)
</p>

<hr />
<h3>Quaternions and octonions</h3>
<p>
<b>Requester:</b> Gary Powell
<br />
<b>Paper: </b>
</p>
<p>
math/octonion & math/quaterion's (used by game designers for 3d math.)
</p>

<hr />
<h3>Units</h3>
<p>
<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>

<hr />
<h3>More STL algorithms</h3>
<p>
<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>

<hr />
<h3>Web services</h3>
<p>
<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>

<hr />
<h3>More special functions</h3>
<p>
<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>

<hr />
<h3>Full-width integer operations</h3>
<p>
<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>.</td>
</p>

<hr />
<h3>Database support</h3>
<p>
<b>Requester:</b> R&uuml;diger Br&uuml;nner, John Medema, Eduardo Y&aacute;nez
<br>
<b>Paper: </b>
</p>
<p>
Generic database support; STL-based recordset operations
</p>

<hr />
<h3>Serialization</h3>
<p>
<b>Requester:</b> R&uuml;diger Br&uuml;nner, Raffaele Mancuso, 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>

<hr />
<h3>Fixed-point arithmetic</h3>
<p>
<b>Requester:</b> R&uuml;diger Br&uuml;nner
<br>
<b>Paper: </b>
</p>
<p>
Fixed-point arithmetic library and currency class based upon it
</p>

<hr />
<h3>Patterns</h3>
<p>
<b>Requester:</b> R&uuml;diger Br&uuml;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>

<hr />
<h3>Interval arithmetic</h3>
<p>
<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>

<hr />
<h3>Class factory implementation</h3>
<p>
<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>

<hr />
<h3>Full support for user-defined memory models</h3>
<p>
<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>

<hr />
<h3>Documentation mechanism</h3>
<p>
<b>Requester:</b> Diego Bragato
<br />
<b>Paper: </b>
</p>

<p>A standardized documentation facility (e.g. doxygen)</p>

<hr />
<h3>Metadata support</h3>
<p>
<b>Requester:</b> Diego Bragato
<br />
<b>Paper: </b>
</p>

<p>A metadata language support (e.g. xdoclet,jdk1.5)</p>

<hr />
<h3>Design paradigms</h3>
<p>
<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>

<hr />
<h3>Design by contract</h3>
<p>
<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>

<hr />
<h3>Aspects</h3>
<p>
<b>Requester:</b> Diego Bragato
<br />
<b>Paper: </b>
</p>

<hr />
<h3>Web service container</h3>
<p>
<b>Requester:</b> Diego Bragato
<br />
<b>Paper: </b>
</p>

<p>Specification for a web service container, 
   taking into account also authentication</p>

<hr />
<h3>map and reserve</h3>
<p>
<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>
<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.</li>
</ol>

<hr />
<h3>Atomic operations</h3>
<p>
<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>

<hr />
<h3>Container-based algorithms</h3>
<p>
<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
{
    // Author &amp; Date:   Kirk Korver     03 Jun 2004
    // Purpose: wrap the std::for_each function to apply the functor to ALL entries
    // Inputs:
    //  c - the container we care about
    //  f - the function or functor we want to apply
    template &lt;class Container, typename Functor> inline
    Functor for_all(Container  &amp; c, Functor &amp; f)
    {
        return std::for_each(c.begin(), c.end(), f);
    }
};
</pre>

<hr />
<h3>Control over containers' threading model</h3>
<p>
<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> 

<hr />
<h3>More convenient way of deallocating vector memory</h3>
<p>
<b>Requester:</b> Tyler Doubrava
<br />
<b>Paper: </b>
</p>

<p>
It would be great if std::vector&lt;> 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>

<hr />
<h3>Lexical analysis and parsing</h3>
<p>
<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 class (and maybe even a yacc
class) added to std::tr2.  The easiest way to see the kind of design I
have in mind is to look at
<a href="http://www.benhanson.net/lexertl.html">http://www.benhanson.net/lexertl.html</a>
(I am the author).  I am aiming to eventually produce a good enough
version that would be accepted by Boost, but I would be perfectly
happy to see someone else do a better job and faster than I can!
</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>

<hr />
<h3>Graphics library</h3>
<p>
<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>

<hr />
<h3>Trees</h3>
<p>
<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>

<hr />
<h3>Data compression</h3>
<p>
<b>Requester:</b> James Buchanan
<br />
<b>Paper: </b> 
</p>

<hr />
<h3>Better support for embedded programming</h3>
<p>
<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>

<hr />
<h3>Specialized iterators and/or algorithms for map iterators</h3>
<p>
<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->().
</p>

<hr />
<h3>Open Unicode-named files</h3>
<p>
<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>

<hr />
<h3>Pervasive TCHAR support</h3>
<p>
<b>Requester:</b> Assaf Lavie
<br />
<b>Paper: </b>
</p>

<p>i.e. standard basic_string&lt;tchar> where tchar compiles to either
    char or wchar_t </p>

<hr />
<h3>Network programming</h3>
<p>
<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", "#" )
</pre>

where "#" is a delimiter string for string parsing (i.e. the stream
contains "1#2#3#4.4#5", and repeated calls nsck >> myString would
yield myString values of 1, 2, 3, 4.4, and 5).
</blockquote>

<hr />
<h3>&lambda; expressions</h3>
<p>
<b>Requester:</b> Assaf Lavie
<br />
<b>Paper: </b>
</p>

<p>lambda expressions - std::for_each is harldy usefull without them.</p>

<hr />
<h3>Better C compatibility</h3>
<p>
<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>

<hr />
<h3>binary_find</h3>
<p>
<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>
     ForwardIterator binary_find(
        ForwardIterator _First, 
        ForwardIterator _Last,
        const Type&amp; _Val
     );
  template&lt;class ForwardIterator, class Type, class BinaryPredicate>
     ForwardIterator binary_find(
        ForwardIterator _First, 
        ForwardIterator _Last,
        const Type&amp; _Val, 
        BinaryPredicate _Comp
     );
 </pre>

<hr />
<h3>Intrusive containers</h3>
<p>
<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>

<hr />
<h3>Better control over hash policy</h3>
<p>
<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>

<!-- -------------------------------------------------- -->

<hr />
<p>
Please sent additions to this list to
<a href="http://lafstern.org/matt/">Matt Austern</a>,
<tt>matt @ lafstern.org</tt>
</p>

</font>
</body>
