]>
Commit | Line | Data |
---|---|---|
7c673cae FG |
1 | <html> |
2 | <head> | |
3 | <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> | |
4 | <title>MultiIndex and Bimap</title> | |
5 | <link rel="stylesheet" href="../../boostbook.css" type="text/css"> | |
6 | <meta name="generator" content="DocBook XSL Stylesheets V1.77.1"> | |
7 | <link rel="home" href="../../index.html" title="Chapter 1. Boost.Bimap"> | |
8 | <link rel="up" href="../history.html" title="History"> | |
9 | <link rel="prev" href="../history.html" title="History"> | |
10 | <link rel="next" href="../acknowledgements.html" title="Acknowledgements"> | |
11 | </head> | |
12 | <body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> | |
13 | <table cellpadding="2" width="100%"><tr> | |
14 | <td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../../boost.png"></td> | |
15 | <td align="center"><a href="../../../../../../index.html">Home</a></td> | |
16 | <td align="center"><a href="../../../../../../libs/libraries.htm">Libraries</a></td> | |
17 | <td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> | |
18 | <td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> | |
19 | <td align="center"><a href="../../../../../../more/index.htm">More</a></td> | |
20 | </tr></table> | |
21 | <hr> | |
22 | <div class="spirit-nav"> | |
23 | <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> | |
24 | </div> | |
25 | <div class="section boost_bimap_history_multiindex_and_bimap"> | |
26 | <div class="titlepage"><div><div><h3 class="title"> | |
27 | <a name="boost_bimap.history.multiindex_and_bimap"></a><a class="link" href="multiindex_and_bimap.html" title="MultiIndex and Bimap">MultiIndex | |
28 | and Bimap</a> | |
29 | </h3></div></div></div> | |
30 | <p> | |
31 | This is the conversation thread that began during Boost.PropertyTree formal | |
32 | review process. The review was very interesting and very deep topics were | |
33 | addressed. It is quite interesting and it is now part of this library history. | |
34 | Enjoy! | |
35 | </p> | |
36 | <p> | |
37 | <span class="bold"><strong>Marcin</strong></span> | |
38 | </p> | |
39 | <div class="blockquote"><blockquote class="blockquote"><p> | |
40 | <span class="emphasis"><em> The biggest virtue of property_tree is easy to use interface. | |
41 | If we try to make generic tree of it, it will be compromised. </em></span> | |
42 | </p></blockquote></div> | |
43 | <p> | |
44 | <span class="bold"><strong>Gennadiy</strong></span> | |
45 | </p> | |
46 | <div class="blockquote"><blockquote class="blockquote"><p> | |
47 | <span class="emphasis"><em> IMO the same result (as library presents) could be achieved | |
48 | just by using multi_index. </em></span> | |
49 | </p></blockquote></div> | |
50 | <p> | |
51 | <span class="bold"><strong>Marcin</strong></span> | |
52 | </p> | |
53 | <div class="blockquote"><blockquote class="blockquote"><p> | |
54 | <span class="emphasis"><em> Could you elaborate more on that? I considered use of multi_index | |
55 | to implement indexing for properties, but it only affected the implementation | |
56 | part of library, not interface, and because I already had a working, exception | |
57 | safe solution, I didn't see the reason to dump it and add another dependency | |
58 | on another library. </em></span> | |
59 | </p></blockquote></div> | |
60 | <p> | |
61 | <span class="bold"><strong>Gennadiy</strong></span> | |
62 | </p> | |
63 | <div class="blockquote"><blockquote class="blockquote"><p> | |
64 | <span class="emphasis"><em> I mean why do I need this half baked property_tree as another | |
65 | data structure? Property tree supports nothing in itself. It's just a data | |
66 | structure. You have parsers that produce property tree out of different | |
67 | sources. But you mat as well produce maps or something else. Here for example | |
68 | All that I need to do to "implement" similar functionality as | |
69 | your property tree: </em></span> | |
70 | </p></blockquote></div> | |
71 | <p> | |
72 | </p> | |
73 | <pre class="programlisting"><span class="comment">// Data structure itself</span> | |
74 | <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> | |
75 | <span class="keyword">struct</span> <span class="identifier">Node</span><span class="special">;</span> | |
76 | <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> | |
77 | <span class="keyword">struct</span> <span class="identifier">ptree_gen</span> <span class="special">{</span> | |
78 | <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> | |
79 | <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> | |
80 | <span class="special">};</span> | |
81 | <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> | |
82 | <span class="keyword">struct</span> <span class="identifier">Node</span> <span class="special">{</span> | |
83 | <span class="identifier">ValueType</span> <span class="identifier">v</span><span class="special">;</span> | |
84 | <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> | |
85 | <span class="special">};</span> | |
86 | <span class="comment">// serialization support</span> | |
87 | <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> | |
88 | <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> | |
89 | <span class="keyword">const</span> <span class="keyword">unsigned</span> <span class="keyword">int</span> <span class="identifier">version</span><span class="special">)</span> | |
90 | <span class="special">{</span> | |
91 | <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> | |
92 | <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> | |
93 | <span class="special">}</span> | |
94 | <span class="comment">// some access methods</span> | |
95 | <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> | |
96 | <span class="identifier">ValueType</span> <span class="keyword">const</span><span class="special">&</span> | |
97 | <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> | |
98 | <span class="special">{</span> | |
99 | <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> | |
100 | <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> | |
101 | <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> | |
102 | <span class="special">}</span> | |
103 | </pre> | |
104 | <p> | |
105 | </p> | |
106 | <div class="blockquote"><blockquote class="blockquote"><p> | |
107 | <span class="emphasis"><em> Use it like this: </em></span> | |
108 | </p></blockquote></div> | |
109 | <p> | |
110 | </p> | |
111 | <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> | |
112 | <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> | |
113 | <span class="identifier">ia</span> <span class="special">>></span> <span class="identifier">PT</span><span class="special">;</span> | |
114 | <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> | |
115 | </pre> | |
116 | <p> | |
117 | </p> | |
118 | <div class="blockquote"><blockquote class="blockquote"><p> | |
119 | <span class="emphasis"><em> Now tell me how property_tree interface is easier? And what | |
120 | is the value in 50k of Code you need to implement this data structure. | |
121 | </em></span> | |
122 | </p></blockquote></div> | |
123 | <p> | |
124 | <span class="bold"><strong>Thorsten</strong></span> | |
125 | </p> | |
126 | <div class="blockquote"><blockquote class="blockquote"><p> | |
127 | <span class="emphasis"><em> Seriously Gennadiy, do you really see newbies writing the code | |
128 | you just did? </em></span> | |
129 | </p></blockquote></div> | |
130 | <p> | |
131 | <span class="bold"><strong>Marcin</strong></span> | |
132 | </p> | |
133 | <div class="blockquote"><blockquote class="blockquote"><p> | |
134 | <span class="emphasis"><em> What you just implemented is stripped down, bare bones version | |
135 | of property_tree that, among other things, does not allow you to produce | |
136 | human editable XML files. Now add more interface (aka get functions), add | |
137 | more archives to serialization lib, add customization, add transparent | |
138 | translation from strings to arbitrary types and vice versa. Spend some | |
139 | weeks trying to get all the corner cases right, and then some more weeks | |
140 | trying to smooth rough edges in the interface. Then write tests. Write | |
141 | docs. At the end, I believe you will not get much less code than there | |
142 | is in the library already. Maybe you get some savings by using multi_index | |
143 | instead of manual indexing. </em></span> | |
144 | </p></blockquote></div> | |
145 | <div class="blockquote"><blockquote class="blockquote"><p> | |
146 | <span class="emphasis"><em> The reason why ptree does not use multi index is because implementation | |
147 | existed long before I considered submitting to boost, probably before even | |
148 | I knew of multi index existence. It was working well. Later, when I was | |
149 | improving it during pre-review process, I seriously considered using multi-index. | |
150 | But I decided it is not worth throwing everything out. </em></span> | |
151 | </p></blockquote></div> | |
152 | <div class="blockquote"><blockquote class="blockquote"><p> | |
153 | <span class="emphasis"><em> Although ptree has large interface with many functions modifying | |
154 | state of the tree, it uses "single point of change" approach. | |
155 | Every insert eventually goes through one function, which takes care of | |
156 | exception safety and keeping index in sync with data. The same applies | |
157 | to erase. This function has 9 lines of code in case of insert, and (by | |
158 | coincidence) also 9 in case of erase. By using multi index these functions | |
159 | would obviously be simplified, maybe to 4 lines each. Net gain: 10 lines | |
160 | of code (out of several hundred in ptree_implementation.hpp). </em></span> | |
161 | </p></blockquote></div> | |
162 | <div class="blockquote"><blockquote class="blockquote"><p> | |
163 | <span class="emphasis"><em> I'm aware that there are performance gains to be reaped as well, | |
164 | but at that time I was rather focusing on getting the interface right. | |
165 | </em></span> | |
166 | </p></blockquote></div> | |
167 | <p> | |
168 | <span class="bold"><strong>Dave</strong></span> | |
169 | </p> | |
170 | <div class="blockquote"><blockquote class="blockquote"><p> | |
171 | <span class="emphasis"><em> That's perfectly reasonable, but (through no fault of yours) | |
172 | it misses the point I was trying to make. I guess I should have said, "...that | |
173 | demonstrates it to be the best implementation." </em></span> | |
174 | </p></blockquote></div> | |
175 | <div class="blockquote"><blockquote class="blockquote"><p> | |
176 | <span class="emphasis"><em> All I'm saying is that the extent to which a Boost library implementation | |
177 | should leverage other Boost libraries is not a question that can always | |
178 | be decided based on following simple guidelines, and that if this library | |
179 | is accepted, it's worth revisiting your decision. </em></span> | |
180 | </p></blockquote></div> | |
181 | <p> | |
182 | <span class="bold"><strong>Thorsten</strong></span> | |
183 | </p> | |
184 | <div class="blockquote"><blockquote class="blockquote"><p> | |
185 | <span class="emphasis"><em> I think it is important to focus on the interface in the review, | |
186 | but I also see several benefits of an implementation that builds on Boost.MultiIndex:' | |
187 | </em></span> | |
188 | </p></blockquote></div> | |
189 | <div class="blockquote"><blockquote class="blockquote"><p> | |
190 | <span class="emphasis"><em>- fewer bugs like the one Joaquin found</em></span> | |
191 | </p></blockquote></div> | |
192 | <div class="blockquote"><blockquote class="blockquote"><p> | |
193 | <span class="emphasis"><em>- better space efficiency</em></span> | |
194 | </p></blockquote></div> | |
195 | <div class="blockquote"><blockquote class="blockquote"><p> | |
196 | <span class="emphasis"><em>- exception-safety guarantees are immediately full-filled (I | |
197 | haven't looked, but I suspect that there are several bugs in this area)</em></span> | |
198 | </p></blockquote></div> | |
199 | <p> | |
200 | <span class="bold"><strong>Daniel</strong></span> | |
201 | </p> | |
202 | <div class="blockquote"><blockquote class="blockquote"><p> | |
203 | <span class="emphasis"><em> Multi_index supports everything a bimap would, but its interface | |
204 | is more cumbersome. I for one won't use a W3DOM-like library if we get | |
205 | one, but I would happily use property_tree. I've also only used multi_index | |
206 | once, and that was to use it as a bidirectional map. Property_tree covers | |
207 | other areas as well as being a potential subset of an XML library, but | |
208 | I still hold there is value in such a subset. </em></span> | |
209 | </p></blockquote></div> | |
210 | <p> | |
211 | <span class="bold"><strong>Boris</strong></span> | |
212 | </p> | |
213 | <div class="blockquote"><blockquote class="blockquote"><p> | |
214 | <span class="emphasis"><em> I haven't used program_options yet. But if I understand correctly | |
215 | both libraries seem to support storing and accessing data with strings | |
216 | that might describe some kind of hierarchy. This seems to be the core idea | |
217 | of both libraries - is this correct? </em></span> | |
218 | </p></blockquote></div> | |
219 | <div class="blockquote"><blockquote class="blockquote"><p> | |
220 | <span class="emphasis"><em> Then it wouldn't matter much what container is used. However | |
221 | a generic tree which can store data hierarchically probably makes most | |
222 | sense. If I understand correctly both libraries could make use of such | |
223 | a class? </em></span> | |
224 | </p></blockquote></div> | |
225 | <p> | |
226 | <span class="bold"><strong>Marcin</strong></span> | |
227 | </p> | |
228 | <div class="blockquote"><blockquote class="blockquote"><p> | |
229 | <span class="emphasis"><em> I think generic tree container is material for another library. | |
230 | Whether property_tree should be based on it or not is a matter of internal | |
231 | implementation, and generally of little interest to users. The biggest | |
232 | value of property_tree is in its easy to use interface, that should not | |
233 | be compromised, if at all possible. I have been already reassured in this | |
234 | view by quite many people who took their time to review the library. </em></span> | |
235 | </p></blockquote></div> | |
236 | <p> | |
237 | <span class="bold"><strong>Boris</strong></span> | |
238 | </p> | |
239 | <div class="blockquote"><blockquote class="blockquote"><p> | |
240 | <span class="emphasis"><em> I was trying to see the big picture: I rather prefer a C++ standard | |
241 | based on a few well-known concepts like containers, iterators, algorithms | |
242 | etc. instead of having a C++ standard with hundreds of components which | |
243 | are tailored for specific needs, collaborate with only a handful of other | |
244 | components and think they provide an easy-to-use interface while all the | |
245 | easy-to-use interfaces make the whole standard less easy-to-use. </em></span> | |
246 | </p></blockquote></div> | |
247 | <div class="blockquote"><blockquote class="blockquote"><p> | |
248 | <span class="emphasis"><em> That said I have used your property tree library myself to read | |
249 | and write a configuration file. It was indeed very easy to use. However | |
250 | it would have been even easier if it was something I had known before like | |
251 | eg. an iterator. For now I will definitely use your property tree library | |
252 | but would appreciate if existing concepts were reused many C++ developers | |
253 | are familiar with. My opinion is that your library should be a part of | |
254 | Boost but should be more generalized in the future. </em></span> | |
255 | </p></blockquote></div> | |
256 | <p> | |
257 | <span class="bold"><strong>Thorsten</strong></span> | |
258 | </p> | |
259 | <div class="blockquote"><blockquote class="blockquote"><p> | |
260 | <span class="emphasis"><em> Well, I think we need both. Boost.MultiIndex is a great library | |
261 | and can do all kinds of wonderful things. But I would still like to see | |
262 | a bidirectional map (boost::bimap) written as a wrapper around it to get | |
263 | an easy and specialized interface. </em></span> | |
264 | </p></blockquote></div> | |
265 | <p> | |
266 | <span class="bold"><strong>Pavel</strong></span> | |
267 | </p> | |
268 | <div class="blockquote"><blockquote class="blockquote"><p> | |
269 | <span class="emphasis"><em> Bimap is available in libs/multi-index/examples/bimap.cpp. | |
270 | </em></span> | |
271 | </p></blockquote></div> | |
272 | <p> | |
273 | <span class="bold"><strong>Thorsten</strong></span> | |
274 | </p> | |
275 | <div class="blockquote"><blockquote class="blockquote"><p> | |
276 | <span class="emphasis"><em> Right, but the real value comes when somebody designs a nice | |
277 | STL-like interface and write docs etc, at least that was my point. </em></span> | |
278 | </p></blockquote></div> | |
279 | <p> | |
280 | <span class="bold"><strong>Dave</strong></span> | |
281 | </p> | |
282 | <div class="blockquote"><blockquote class="blockquote"><p> | |
283 | <span class="emphasis"><em> IMO Thorsten is exactly right. This is precisely the sort of | |
284 | thing that could be added to the library as part of its ongoing maintenance | |
285 | and development (without review, of course). </em></span> | |
286 | </p></blockquote></div> | |
287 | <p> | |
288 | <span class="bold"><strong>Joaquin</strong></span> | |
289 | </p> | |
290 | <div class="blockquote"><blockquote class="blockquote"><p> | |
291 | <span class="emphasis"><em> Thorsten, we have talked about this privately in the past, but | |
292 | I feel like bringing it to the list in the hope of getting the attention | |
293 | of potential contributors: </em></span> | |
294 | </p></blockquote></div> | |
295 | <div class="blockquote"><blockquote class="blockquote"><p> | |
296 | <span class="emphasis"><em> There are some data structures buildable with B.MI which are | |
297 | regarded as particularly useful or common, like for instance the bidirectional | |
298 | map or bimap. A lean and mean implementation is provided in the aforementioned | |
299 | example, but certainly a much carefully crafted interface can be provided | |
300 | keeping B.MI as the implementation core: operator[], selection of 1-1/1-N/N-1/N-N | |
301 | variants, hashing/ordering, etc. </em></span> | |
302 | </p></blockquote></div> | |
303 | <div class="blockquote"><blockquote class="blockquote"><p> | |
304 | <span class="emphasis"><em> I'm afraid I don't have the time to pursue this, as the current | |
305 | roadmap for core features of B.MI is taking all the spare time I can dedicate | |
306 | to the library. For this reason, I would love to see some volunteer jumping | |
307 | in who can develop this and other singular containers using B.MI (a cache | |
308 | container comes to mind) and then propose the results here either as a | |
309 | stand alone library of as part of B.MI --I'd prefer the former so as to | |
310 | keep the size of B.MI bounded. </em></span> | |
311 | </p></blockquote></div> | |
312 | <div class="blockquote"><blockquote class="blockquote"><p> | |
313 | <span class="emphasis"><em> If there's such a volunteer I can provide her with some help/mentoring. | |
314 | I also wonder whether this is a task suitable to be proposed for Google | |
315 | Summer of Code. </em></span> | |
316 | </p></blockquote></div> | |
317 | <p> | |
318 | <span class="bold"><strong>Thorsten</strong></span> | |
319 | </p> | |
320 | <div class="blockquote"><blockquote class="blockquote"><p> | |
321 | <span class="emphasis"><em> I think it would be good for SOC. All the really hard things | |
322 | are taken care of by B.MI, and so it seems reasonable for a student to | |
323 | be able to fill in the details. </em></span> | |
324 | </p></blockquote></div> | |
325 | <p> | |
326 | <span class="bold"><strong>Dave</strong></span> | |
327 | </p> | |
328 | <div class="blockquote"><blockquote class="blockquote"><p> | |
329 | <span class="emphasis"><em> Great! </em></span> | |
330 | </p></blockquote></div> | |
331 | <p> | |
332 | <span class="bold"><strong>Jeff</strong></span> | |
333 | </p> | |
334 | <div class="blockquote"><blockquote class="blockquote"><p> | |
335 | <span class="emphasis"><em> Please write a proposal! </em></span> | |
336 | </p></blockquote></div> | |
337 | <p> | |
338 | <span class="bold"><strong>Joaquin</strong></span> | |
339 | </p> | |
340 | <div class="blockquote"><blockquote class="blockquote"><p> | |
341 | <span class="emphasis"><em> I've just done so: </em></span> | |
342 | </p></blockquote></div> | |
343 | <div class="sidebar"> | |
344 | <div class="titlepage"></div> | |
345 | <p> | |
346 | <span class="bold"><strong>Specialized containers with Boost.MultiIndex</strong></span> | |
347 | </p> | |
348 | <p> | |
349 | <span class="bold"><strong>Introduction</strong></span> | |
350 | </p> | |
351 | <p> | |
352 | Boost.MultiIndex allows the construction of complex data structures involving | |
353 | two or more indexing mechanisms on the same set of elements. Out of the unlimited | |
354 | range of possible data structures specifiable within Boost.MultiIndex, some | |
355 | particular configurations arise recurrently: | |
356 | </p> | |
357 | <p> | |
358 | <span class="bold"><strong>a.</strong></span> A bidirectional map or bimap is a container | |
359 | of elements of type pair<T,Q> where fast look up is provided both for | |
360 | the T and the Q field, in contrast with a regular STL map which only allows | |
361 | for fast look up on T. | |
362 | </p> | |
363 | <p> | |
364 | <span class="bold"><strong>b.</strong></span> An MRU (most recently used) list keeps | |
365 | the n last referenced elements: when a new item is inserted and the list | |
366 | has reached its maximum length, the oldest element is erased, whereas if | |
367 | an insertion is tried of a preexistence element, this gets promoted to the | |
368 | first position. MRU lists can be used to implement dynamic caches and the | |
369 | kind of behavior exhibited by programs featuring a "Recent files" | |
370 | menu command, for instance. | |
371 | </p> | |
372 | <p> | |
373 | Although Boost.MultiIndex provides the mechanisms to build these common structures, | |
374 | the resulting interface can be cumbersome and too general in comparison with | |
375 | specialized containers focusing on such particular structures. | |
376 | </p> | |
377 | <p> | |
378 | <span class="bold"><strong>Goal</strong></span> | |
379 | </p> | |
380 | <p> | |
381 | To write a library of specialized containers like the ones described above, | |
382 | using Boost.MultiIndex as the implementation core. Besides bimap and MRU | |
383 | list, the student can also propose other specialized containers of interest | |
384 | in the community. It is expected that the library meets the standards of | |
385 | quality required by Boost for an eventual inclusion in this project, which | |
386 | implies a strong emphasis on interface design, documentation and unit testing; | |
387 | the mentor will be guiding the student through the complete cycle from specification | |
388 | and requirements gathering to documentation and actual coding. The final | |
389 | result of the project must then contain: | |
390 | </p> | |
391 | <p> | |
392 | <span class="bold"><strong>a.</strong></span> Source code following <a href="http://boost.org/more/lib_guide.htm#Guidelines" target="_top">Boost | |
393 | programming guidelines</a>. | |
394 | </p> | |
395 | <p> | |
396 | <span class="bold"><strong>b.</strong></span> User documentation. Requirements on the | |
397 | format are loose, though the <a href="http://www.boost.org/tools/quickbook/" target="_top">QuickBook</a> | |
398 | format is gaining acceptance within Boost. | |
399 | </p> | |
400 | <p> | |
401 | <span class="bold"><strong>c.</strong></span> Complete set of unit tests powered by | |
402 | <a href="http://www.boost.org/boost-build2/" target="_top">Boost Build System V2</a>. | |
403 | </p> | |
404 | <p> | |
405 | <span class="bold"><strong>Requirements</strong></span> | |
406 | </p> | |
407 | <p> | |
408 | <span class="bold"><strong>a.</strong></span> Intermediate-to-high level in C++, with | |
409 | emphasis in generic programming (templates). | |
410 | </p> | |
411 | <p> | |
412 | <span class="bold"><strong>b.</strong></span> Knowledge of the STL framework and design | |
413 | principles. Of course, knowledge of Boost in general and Boost.MultiIndex | |
414 | in particular is a big plus. | |
415 | </p> | |
416 | <p> | |
417 | <span class="bold"><strong>c.</strong></span> Acquaintance with at least two different | |
418 | C++ programming environments. | |
419 | </p> | |
420 | <p> | |
421 | <span class="bold"><strong>d.</strong></span> Some fluency in the English language; | |
422 | subsequent reviews of the documentation can help smooth rough edges here, | |
423 | though. | |
424 | </p> | |
425 | <p> | |
426 | <span class="bold"><strong>e.</strong></span> A mathematical inclination and previous | |
427 | exposure to a formal Algorithms course would help very much. | |
428 | </p> | |
429 | <p> | |
430 | <span class="bold"><strong>f.</strong></span> A craving for extreme quality work. | |
431 | </p> | |
432 | <p> | |
433 | <span class="bold"><strong>Benefits for the student</strong></span> | |
434 | </p> | |
435 | <p> | |
436 | The student taking on this project will have the opportunity to learn the | |
437 | complete process of software production inside a highly regarded C++ open | |
438 | source institution, and even see her work included in Boost eventually. The | |
439 | completion of the project involves non-trivial problems in C++ interface | |
440 | design and so-called modern C++ programming, high quality user documentation | |
441 | and unit testing. The student will also learn, perhaps to her surprise, that | |
442 | most of the time will be spent gathering and trying ideas and, in general, | |
443 | thinking, rather than writing actual code. | |
444 | </p> | |
445 | </div> | |
446 | <p> | |
447 | <span class="bold"><strong>Matias</strong></span> | |
448 | </p> | |
449 | <div class="blockquote"><blockquote class="blockquote"><p> | |
450 | <span class="emphasis"><em> I am planning to submit an application to SoC. I will love to | |
451 | make real the specialized containers you mention and try to include some | |
452 | useful others. </em></span> | |
453 | </p></blockquote></div> | |
454 | <div class="blockquote"><blockquote class="blockquote"><p> | |
455 | <code class="literal"> And then... after long hours of coding (and fun) this library | |
456 | saw the light. </code> | |
457 | </p></blockquote></div> | |
458 | <div class="blockquote"><blockquote class="blockquote"><p> | |
459 | <span class="inlinemediaobject"><img src="../../images/bimap/boost.bimap.logo.png" alt="boost.bimap.logo"></span> | |
460 | </p></blockquote></div> | |
461 | </div> | |
462 | <table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> | |
463 | <td align="left"></td> | |
464 | <td align="right"><div class="copyright-footer">Copyright © 2006-2012 Matias Capeletto<p> | |
465 | Distributed under the Boost Software License, Version 1.0. (See accompanying | |
466 | 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>) | |
467 | </p> | |
468 | </div></td> | |
469 | </tr></table> | |
470 | <hr> | |
471 | <div class="spirit-nav"> | |
472 | <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> | |
473 | </div> | |
474 | </body> | |
475 | </html> |