<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>MultiIndex and Bimap</title>
<link rel="stylesheet" href="../../boostbook.css" type="text/css">
<meta name="generator" content="DocBook XSL Stylesheets V1.75.2">
<link rel="home" href="../../index.html" title="Chapter 1. Boost.Bimap">
<link rel="up" href="../history.html" title="History">
<link rel="prev" href="../history.html" title="History">
<link rel="next" href="../acknowledgements.html" title="Acknowledgements">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table cellpadding="2" width="100%"><tr>
<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../../boost.png"></td>
<td align="center"><a href="../../../../../../index.html">Home</a></td>
<td align="center"><a href="../../../../../../libs/libraries.htm">Libraries</a></td>
<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td>
<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td>
<td align="center"><a href="../../../../../../more/index.htm">More</a></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="../history.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../history.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="../acknowledgements.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
</div>
<div class="section">
<div class="titlepage"><div><div><h3 class="title">
<a name="boost_bimap.history.multiindex_and_bimap"></a><a class="link" href="multiindex_and_bimap.html" title="MultiIndex and Bimap">MultiIndex
and Bimap</a>
</h3></div></div></div>
<p>
This is the conversation thread that began during Boost.PropertyTree formal
review process. The review was very interesting and very deep topics were
addressed. It is quite interesting and it is now part of this library history.
Enjoy!
</p>
<p>
<span class="bold"><strong>Marcin</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> The biggest virtue of property_tree is easy to use interface.
If we try to make generic tree of it, it will be compromised. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Gennadiy</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> IMO the same result (as library presents) could be achieved
just by using multi_index. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Marcin</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Could you elaborate more on that? I considered use of multi_index
to implement indexing for properties, but it only affected the implementation
part of library, not interface, and because I already had a working, exception
safe solution, I didn't see the reason to dump it and add another dependency
on another library. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Gennadiy</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I mean why do I need this half baked property_tree as another
data structure? Property tree supports nothing in itself. It's just a data
structure. You have parsers that produce property tree out of different
sources. But you mat as well produce maps or something else. Here for example
All that I need to do to "implement" similar functionality as
your property tree: </em></span>
</p></blockquote></div>
<p>
</p>
<pre class="programlisting"><span class="comment">// Data structure itself
</span><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">ValueType</span><span class="special">,</span><span class="keyword">typename</span> <span class="identifier">KeyType</span><span class="special">></span>
<span class="keyword">struct</span> <span class="identifier">Node</span><span class="special">;</span>
<span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">ValueType</span><span class="special">,</span><span class="keyword">typename</span> <span class="identifier">KeyType</span><span class="special">></span>
<span class="keyword">struct</span> <span class="identifier">ptree_gen</span> <span class="special">{</span>
<span class="keyword">typedef</span> <span class="identifier">std</span><span class="special">::</span><span class="identifier">pair</span><span class="special"><</span><span class="identifier">KeyType</span><span class="special">,</span><span class="identifier">Node</span><span class="special"><</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">></span> <span class="special">></span> <span class="identifier">mi_value</span><span class="special">;</span>
<span class="keyword">typedef</span> <span class="identifier">multi_index_container</span><span class="special"><</span><span class="identifier">mi_value</span><span class="special">,</span> <span class="identifier">indexed_by</span><span class="special"><...></span> <span class="special">></span> <span class="identifier">type</span><span class="special">;</span>
<span class="special">};</span>
<span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">ValueType</span><span class="special">,</span><span class="keyword">typename</span> <span class="identifier">KeyType</span><span class="special">></span>
<span class="keyword">struct</span> <span class="identifier">Node</span> <span class="special">{</span>
<span class="identifier">ValueType</span> <span class="identifier">v</span><span class="special">;</span>
<span class="identifier">ptree_gen</span><span class="special"><</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">>::</span><span class="identifier">type</span> <span class="identifier">children</span><span class="special">;</span>
<span class="special">};</span>
<span class="comment">// serialization support
</span><span class="keyword">template</span><span class="special"><</span><span class="keyword">class</span> <span class="identifier">Archive</span><span class="special">,</span><span class="keyword">typename</span> <span class="identifier">ValueType</span><span class="special">,</span><span class="keyword">typename</span> <span class="identifier">KeyType</span><span class="special">></span>
<span class="keyword">void</span> <span class="identifier">serialize</span><span class="special">(</span><span class="identifier">Archive</span> <span class="special">&</span> <span class="identifier">ar</span><span class="special">,</span> <span class="identifier">Node</span><span class="special"><</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">>&</span> <span class="identifier">n</span><span class="special">,</span>
<span class="keyword">const</span> <span class="keyword">unsigned</span> <span class="keyword">int</span> <span class="identifier">version</span><span class="special">)</span>
<span class="special">{</span>
<span class="identifier">ar</span> <span class="special">&</span> <span class="identifier">n</span><span class="special">.</span><span class="identifier">v</span><span class="special">;</span>
<span class="identifier">ar</span> <span class="special">&</span> <span class="identifier">n</span><span class="special">.</span><span class="identifier">children</span><span class="special">;</span>
<span class="special">}</span>
<span class="comment">// some access methods
</span><span class="keyword">template</span><span class="special"><</span><span class="keyword">typename</span> <span class="identifier">ValueType</span><span class="special">,</span><span class="keyword">typename</span> <span class="identifier">KeyType</span><span class="special">></span>
<span class="identifier">ValueType</span> <span class="keyword">const</span><span class="special">&</span>
<span class="identifier">get</span><span class="special">(</span> <span class="identifier">string</span> <span class="keyword">const</span><span class="special">&</span> <span class="identifier">keys</span><span class="special">,</span> <span class="identifier">ptree_gen</span><span class="special"><</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">>::</span><span class="identifier">type</span> <span class="keyword">const</span><span class="special">&</span> <span class="identifier">src</span> <span class="special">)</span>
<span class="special">{</span>
<span class="identifier">std</span><span class="special">::</span><span class="identifier">pait</span><span class="special"><</span><span class="identifier">string</span><span class="special">,</span><span class="identifier">string</span><span class="special">></span> <span class="identifier">sk</span> <span class="special">=</span> <span class="identifier">split</span><span class="special">(</span> <span class="identifier">keys</span><span class="special">,</span> <span class="string">"."</span> <span class="special">);</span>
<span class="identifier">Node</span> <span class="keyword">const</span><span class="special">&</span> <span class="identifier">N</span> <span class="special">=</span> <span class="identifier">src</span><span class="special">.</span><span class="identifier">find</span><span class="special">(</span> <span class="identifier">sk</span><span class="special">.</span><span class="identifier">first</span> <span class="special">);</span>
<span class="keyword">return</span> <span class="identifier">sk</span><span class="special">.</span><span class="identifier">second</span><span class="special">.</span><span class="identifier">empty</span><span class="special">()</span> <span class="special">?</span> <span class="identifier">N</span><span class="special">.</span><span class="identifier">v</span> <span class="special">:</span> <span class="identifier">get</span><span class="special">(</span> <span class="identifier">sk</span><span class="special">.</span><span class="identifier">second</span><span class="special">,</span> <span class="identifier">N</span><span class="special">.</span><span class="identifier">children</span> <span class="special">);</span>
<span class="special">}</span>
</pre>
<p>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Use it like this: </em></span>
</p></blockquote></div>
<p>
</p>
<pre class="programlisting"><span class="identifier">ptree_gen</span><span class="special"><</span><span class="identifier">string</span><span class="special">,</span><span class="identifier">string</span><span class="special">>::</span><span class="identifier">type</span> <span class="identifier">PT</span><span class="special">;</span>
<span class="identifier">boost</span><span class="special">::</span><span class="identifier">archive</span><span class="special">::</span><span class="identifier">text_iarchive</span> <span class="identifier">ia</span><span class="special">(</span> <span class="identifier">std</span><span class="special">::</span><span class="identifier">ifstream</span> <span class="identifier">ifs</span><span class="special">(</span><span class="string">"filename"</span><span class="special">)</span> <span class="special">);</span>
<span class="identifier">ia</span> <span class="special">>></span> <span class="identifier">PT</span><span class="special">;</span>
<span class="identifier">string</span> <span class="identifier">value</span> <span class="special">=</span> <span class="identifier">get</span><span class="special">(</span> <span class="string">"a.b.c.d"</span><span class="special">,</span> <span class="identifier">PT</span> <span class="special">);</span>
</pre>
<p>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Now tell me how property_tree interface is easier? And what
is the value in 50k of Code you need to implement this data structure.
</em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Thorsten</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Seriously Gennadiy, do you really see newbies writing the code
you just did? </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Marcin</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> What you just implemented is stripped down, bare bones version
of property_tree that, among other things, does not allow you to produce
human editable XML files. Now add more interface (aka get functions), add
more archives to serialization lib, add customization, add transparent
translation from strings to arbitrary types and vice versa. Spend some
weeks trying to get all the corner cases right, and then some more weeks
trying to smooth rough edges in the interface. Then write tests. Write
docs. At the end, I believe you will not get much less code than there
is in the library already. Maybe you get some savings by using multi_index
instead of manual indexing. </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> The reason why ptree does not use multi index is because implementation
existed long before I considered submitting to boost, probably before even
I knew of multi index existence. It was working well. Later, when I was
improving it during pre-review process, I seriously considered using multi-index.
But I decided it is not worth throwing everything out. </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Although ptree has large interface with many functions modifying
state of the tree, it uses "single point of change" approach.
Every insert eventually goes through one function, which takes care of
exception safety and keeping index in sync with data. The same applies
to erase. This function has 9 lines of code in case of insert, and (by
coincidence) also 9 in case of erase. By using multi index these functions
would obviously be simplified, maybe to 4 lines each. Net gain: 10 lines
of code (out of several hundred in ptree_implementation.hpp). </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I'm aware that there are performance gains to be reaped as well,
but at that time I was rather focusing on getting the interface right.
</em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Dave</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> That's perfectly reasonable, but (through no fault of yours)
it misses the point I was trying to make. I guess I should have said, "...that
demonstrates it to be the best implementation." </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> All I'm saying is that the extent to which a Boost library implementation
should leverage other Boost libraries is not a question that can always
be decided based on following simple guidelines, and that if this library
is accepted, it's worth revisiting your decision. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Thorsten</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I think it is important to focus on the interface in the review,
but I also see several benefits of an implementation that builds on Boost.MultiIndex:'
</em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>- fewer bugs like the one Joaquin found</em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>- better space efficiency</em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em>- exception-safety guarantees are immediately full-filled (I
haven't looked, but I suspect that there are several bugs in this area)</em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Daniel</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Multi_index supports everything a bimap would, but its interface
is more cumbersome. I for one won't use a W3DOM-like library if we get
one, but I would happily use property_tree. I've also only used multi_index
once, and that was to use it as a bidirectional map. Property_tree covers
other areas as well as being a potential subset of an XML library, but
I still hold there is value in such a subset. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Boris</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I haven't used program_options yet. But if I understand correctly
both libraries seem to support storing and accessing data with strings
that might describe some kind of hierarchy. This seems to be the core idea
of both libraries - is this correct? </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Then it wouldn't matter much what container is used. However
a generic tree which can store data hierarchically probably makes most
sense. If I understand correctly both libraries could make use of such
a class? </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Marcin</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I think generic tree container is material for another library.
Whether property_tree should be based on it or not is a matter of internal
implementation, and generally of little interest to users. The biggest
value of property_tree is in its easy to use interface, that should not
be compromised, if at all possible. I have been already reassured in this
view by quite many people who took their time to review the library. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Boris</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I was trying to see the big picture: I rather prefer a C++ standard
based on a few well-known concepts like containers, iterators, algorithms
etc. instead of having a C++ standard with hundreds of components which
are tailored for specific needs, collaborate with only a handful of other
components and think they provide an easy-to-use interface while all the
easy-to-use interfaces make the whole standard less easy-to-use. </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> That said I have used your property tree library myself to read
and write a configuration file. It was indeed very easy to use. However
it would have been even easier if it was something I had known before like
eg. an iterator. For now I will definitely use your property tree library
but would appreciate if existing concepts were reused many C++ developers
are familiar with. My opinion is that your library should be a part of
Boost but should be more generalized in the future. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Thorsten</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Well, I think we need both. Boost.MultiIndex is a great library
and can do all kinds of wonderful things. But I would still like to see
a bidirectional map (boost::bimap) written as a wrapper around it to get
an easy and specialized interface. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Pavel</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Bimap is available in libs/multi-index/examples/bimap.cpp.
</em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Thorsten</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Right, but the real value comes when somebody designs a nice
STL-like interface and write docs etc, at least that was my point. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Dave</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> IMO Thorsten is exactly right. This is precisely the sort of
thing that could be added to the library as part of its ongoing maintenance
and development (without review, of course). </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Joaquin</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Thorsten, we have talked about this privately in the past, but
I feel like bringing it to the list in the hope of getting the attention
of potential contributors: </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> There are some data structures buildable with B.MI which are
regarded as particularly useful or common, like for instance the bidirectional
map or bimap. A lean and mean implementation is provided in the aforementioned
example, but certainly a much carefully crafted interface can be provided
keeping B.MI as the implementation core: operator[], selection of 1-1/1-N/N-1/N-N
variants, hashing/ordering, etc. </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I'm afraid I don't have the time to pursue this, as the current
roadmap for core features of B.MI is taking all the spare time I can dedicate
to the library. For this reason, I would love to see some volunteer jumping
in who can develop this and other singular containers using B.MI (a cache
container comes to mind) and then propose the results here either as a
stand alone library of as part of B.MI --I'd prefer the former so as to
keep the size of B.MI bounded. </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> If there's such a volunteer I can provide her with some help/mentoring.
I also wonder whether this is a task suitable to be proposed for Google
Summer of Code. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Thorsten</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I think it would be good for SOC. All the really hard things
are taken care of by B.MI, and so it seems reasonable for a student to
be able to fill in the details. </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Dave</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Great! </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Jeff</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> Please write a proposal! </em></span>
</p></blockquote></div>
<p>
<span class="bold"><strong>Joaquin</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I've just done so: </em></span>
</p></blockquote></div>
<div class="sidebar">
<p class="title"><b></b></p>
<p>
<span class="bold"><strong>Specialized containers with Boost.MultiIndex</strong></span>
</p>
<p>
<span class="bold"><strong>Introduction</strong></span>
</p>
<p>
Boost.MultiIndex allows the construction of complex data structures involving
two or more indexing mechanisms on the same set of elements. Out of the unlimited
range of possible data structures specifiable within Boost.MultiIndex, some
particular configurations arise recurrently:
</p>
<p>
<span class="bold"><strong>a.</strong></span> A bidirectional map or bimap is a container
of elements of type pair<T,Q> where fast look up is provided both for
the T and the Q field, in contrast with a regular STL map which only allows
for fast look up on T.
</p>
<p>
<span class="bold"><strong>b.</strong></span> An MRU (most recently used) list keeps
the n last referenced elements: when a new item is inserted and the list
has reached its maximum length, the oldest element is erased, whereas if
an insertion is tried of a preexistence element, this gets promoted to the
first position. MRU lists can be used to implement dynamic caches and the
kind of behavior exhibited by programs featuring a "Recent files"
menu command, for instance.
</p>
<p>
Although Boost.MultiIndex provides the mechanisms to build these common structures,
the resulting interface can be cumbersome and too general in comparison with
specialized containers focusing on such particular structures.
</p>
<p>
<span class="bold"><strong>Goal</strong></span>
</p>
<p>
To write a library of specialized containers like the ones described above,
using Boost.MultiIndex as the implementation core. Besides bimap and MRU
list, the student can also propose other specialized containers of interest
in the community. It is expected that the library meets the standards of
quality required by Boost for an eventual inclusion in this project, which
implies a strong emphasis on interface design, documentation and unit testing;
the mentor will be guiding the student through the complete cycle from specification
and requirements gathering to documentation and actual coding. The final
result of the project must then contain:
</p>
<p>
<span class="bold"><strong>a.</strong></span> Source code following <a href="http://boost.org/more/lib_guide.htm#Guidelines" target="_top">Boost
programming guidelines</a>.
</p>
<p>
<span class="bold"><strong>b.</strong></span> User documentation. Requirements on the
format are loose, though the <a href="http://www.boost.org/tools/quickbook/doc/html/index.html" target="_top">QuickBook</a>
format is gaining acceptance within Boost.
</p>
<p>
<span class="bold"><strong>c.</strong></span> Complete set of unit tests powered by
<a href="http://boost.sourceforge.net/boost-build2/" target="_top">Boost Build System
V2</a>.
</p>
<p>
<span class="bold"><strong>Requirements</strong></span>
</p>
<p>
<span class="bold"><strong>a.</strong></span> Intermediate-to-high level in C++, with
emphasis in generic programming (templates).
</p>
<p>
<span class="bold"><strong>b.</strong></span> Knowledge of the STL framework and design
principles. Of course, knowledge of Boost in general and Boost.MultiIndex
in particular is a big plus.
</p>
<p>
<span class="bold"><strong>c.</strong></span> Acquaintance with at least two different
C++ programming environments.
</p>
<p>
<span class="bold"><strong>d.</strong></span> Some fluency in the English language;
subsequent reviews of the documentation can help smooth rough edges here,
though.
</p>
<p>
<span class="bold"><strong>e.</strong></span> A mathematical inclination and previous
exposure to a formal Algorithms course would help very much.
</p>
<p>
<span class="bold"><strong>f.</strong></span> A craving for extreme quality work.
</p>
<p>
<span class="bold"><strong>Benefits for the student</strong></span>
</p>
<p>
The student taking on this project will have the opportunity to learn the
complete process of software production inside a highly regarded C++ open
source institution, and even see her work included in Boost eventually. The
completion of the project involves non-trivial problems in C++ interface
design and so-called modern C++ programming, high quality user documentation
and unit testing. The student will also learn, perhaps to her surprise, that
most of the time will be spent gathering and trying ideas and, in general,
thinking, rather than writing actual code.
</p>
</div>
<p>
<span class="bold"><strong>Matias</strong></span>
</p>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="emphasis"><em> I am planning to submit an application to SoC. I will love to
make real the specialized containers you mention and try to include some
useful others. </em></span>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<code class="literal"> And then... after long hours of coding (and fun) this library
saw the light. </code>
</p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
<span class="inlinemediaobject"><img src="../../images/bimap/boost.bimap.logo.png" alt="boost.bimap.logo"></span>
</p></blockquote></div>
</div>
<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr>
<td align="left"></td>
<td align="right"><div class="copyright-footer">Copyright © 2006 -2007 Matias Capeletto<p>
Distributed under the Boost Software License, Version 1.0. (See accompanying
file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
</p>
</div></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="../history.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../history.html"><img src="../../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../../index.html"><img src="../../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="../acknowledgements.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
</div>
</body>
</html>
