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