devn00b
/
EQ2EMu


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475
							<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.79.1">
<link rel="home" href="../../index.html" title="Chapter&#160;1.&#160;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">&lt;</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">&gt;</span>
<span class="keyword">struct</span> <span class="identifier">Node</span><span class="special">;</span>
<span class="keyword">template</span><span class="special">&lt;</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">&gt;</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">&lt;</span><span class="identifier">KeyType</span><span class="special">,</span><span class="identifier">Node</span><span class="special">&lt;</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">&gt;</span> <span class="special">&gt;</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">&lt;</span><span class="identifier">mi_value</span><span class="special">,</span> <span class="identifier">indexed_by</span><span class="special">&lt;...&gt;</span> <span class="special">&gt;</span> <span class="identifier">type</span><span class="special">;</span>
<span class="special">};</span>
<span class="keyword">template</span><span class="special">&lt;</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">&gt;</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">&lt;</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">&gt;::</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">&lt;</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">&gt;</span>
<span class="keyword">void</span> <span class="identifier">serialize</span><span class="special">(</span><span class="identifier">Archive</span> <span class="special">&amp;</span> <span class="identifier">ar</span><span class="special">,</span> <span class="identifier">Node</span><span class="special">&lt;</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">&gt;&amp;</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">&amp;</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">&amp;</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">&lt;</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">&gt;</span>
<span class="identifier">ValueType</span> <span class="keyword">const</span><span class="special">&amp;</span>
<span class="identifier">get</span><span class="special">(</span> <span class="identifier">string</span> <span class="keyword">const</span><span class="special">&amp;</span> <span class="identifier">keys</span><span class="special">,</span> <span class="identifier">ptree_gen</span><span class="special">&lt;</span><span class="identifier">ValueType</span><span class="special">,</span><span class="identifier">KeyType</span><span class="special">&gt;::</span><span class="identifier">type</span> <span class="keyword">const</span><span class="special">&amp;</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">&lt;</span><span class="identifier">string</span><span class="special">,</span><span class="identifier">string</span><span class="special">&gt;</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">&amp;</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">&lt;</span><span class="identifier">string</span><span class="special">,</span><span class="identifier">string</span><span class="special">&gt;::</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">&gt;&gt;</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="blurb">
<div class="titlepage"><div><div><p class="title"><b></b></p></div></div></div>
<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&lt;T,Q&gt; 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/" 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://www.boost.org/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 &#169; 2006-2012 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>