123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761 |
- <html>
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
- <title>The student and the mentor</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 1. Boost.Bimap">
- <link rel="up" href="../rationale.html" title="Rationale">
- <link rel="prev" href="code.html" title="Code">
- <link rel="next" href="../history.html" title="History">
- </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="code.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../rationale.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="../history.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.rationale.the_student_and_the_mentor"></a><a class="link" href="the_student_and_the_mentor.html" title="The student and the mentor">The
- student and the mentor</a>
- </h3></div></div></div>
- <div class="tip"><table border="0" summary="Tip">
- <tr>
- <td rowspan="2" align="center" valign="top" width="25"><img alt="[Tip]" src="../../../../../../doc/src/images/tip.png"></td>
- <th align="left">Tip</th>
- </tr>
- <tr><td align="left" valign="top"><p>
- It is a good idea to read the original <a href="http://h1.ripway.com/mcape/boost/libs/misc/" target="_top">Boost.Misc
- SoC proposal</a> first.
- </p></td></tr>
- </table></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <code class="literal">- The discussion starts with Joaquin trying to strip out the "misc"
- name out of the library -</code>
- </p></blockquote></div>
- <p>
- <span class="inlinemediaobject"><img src="../../images/people/joaquin.png" alt="joaquin"></span>
- </p>
- <p>
- <span class="bold"><strong>Joaquin</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Thinking about it, the unifying principle of MISC containers
- is perhaps misleading: certainly all miscs use multi-indexing internally,
- but this does not reflect much in the external interface (as it should
- be, OTOH). So, from the user's point of view, miscs are entirely heterogeneous
- beasts. Moreover, there isn't in your proposal any kind of global facility
- common to all miscs. What about dropping the misc principle and working
- on each container as a separate library, then? You'd have boost::bimap,
- boost::mru, etc, and no common intro to them. This also opens up the possibility
- to add other containers to the suite which aren't based on B.MI. What's
- your stance on this? Do you see a value in keeping miscs conceptually together?
- </em></span>
- </p></blockquote></div>
- <p>
- <span class="inlinemediaobject"><img src="../../images/people/matias.png" alt="matias"></span>
- </p>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> As the original proposal states only two containers (bimap and
- mru set) both based in B.MI, it was straight forward to group them together.
- When I was writing the SoC proposal I experienced a similar feeling when
- the two families begin to grow. As you say, the only common denominator
- is their internal implementation. I thought a bit about a more general
- framework to join this two families (and other internally related ones)
- and finally came up with an idea: Boost.MultiIndex! So I think that it
- is not a good idea to try to unify the two families and I voted in favor
- of get rid of the misc part of boost::misc::bimap and boost::misc::mru.
- Anyway, for my SoC application it seems OK to put the two families in the
- same project because although from the outside they are completely unrelated,
- the work I will have to do in order to build the libraries will be consistent
- and what I will learn coding the bimap family will be used when I start
- to code the mru family. When the mru family is in place, I will surely
- have learnt other things to improve the bimap group. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> On the other hand, I think it will be useful for the general
- user to have at least some document linked in the B.MI documentation that
- enumerates the most common cases of uses (a bimap and an mru set for example)
- and points where to find clean implementation for this useful containers.
- For now, a link to boost::bimap and other one to boost::mru will suffice.
- If you think about the title of such a document, you will probably come
- up with something like: Common Multi Index Specialized Containers, and
- we are back to our misc proposal. So, to order some ideas: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- A new family of containers that can be accessed by both key
- will be created. (boost::bimap)</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- A new family of time aware containers will see the light. (boost::mru)</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- A page can be added to B.MI documentation, titled misc that
- links this new libraries.</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> This is a clearer framework for the user. They can use a mru
- container without hearing about Boost.MultiIndex at all. And B.MI users
- will get some of their common containers already implemented with an STL
- friendly interface in other libraries. And as you stated this is more extensible
- because opens the door to use other libraries in bimap and mru families
- than just Boost.MultiIndex without compromising the more general boost
- framework. The word "misc" it is going to disappear from the
- code and the documentation of bimap and mru. From now on the only use for
- it will be to identify our SoC project. I am thinking in a name for the
- bimap library. What about Boost.BidirectionalMap? Ideas? </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> Yes, Boost.Bimap. In my opinion, bimap is a well known name
- in the Boost and even in the C++ community. It sounds and is short. Why
- not to vindicate yourself as the owner of this name? </em></span>
- </p></blockquote></div>
- <p>
- <code class="literal">- Then after a week of work -</code>
- </p>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Now that Boost.Bimap is getting some shape, I see that as you
- have told me, we must offer a "one_to_many_map" and a "multi_bimap"
- as part of the library. The framework I am actually working allowed to
- construct this kind of bidirectional maps and it is easy to understand
- from the user side. </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> OK, I am glad we agree on this point. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> With respect to the symmetry of the key access names, I have
- to agree that there is not much a difference between the following ones:
- </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- to - from</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- to - b</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- 0 - 1</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- left - right</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> In my opinion it is a matter of taste, but left/right sounds
- more symmetrical than the others. </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 like very much the left/right notation, it is very simple
- to remember and it is a lot more symmetrical than to/from. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> At first my idea was to obtain ease of use hiding the B.MI core,
- making it more STL-intuitive. Nevertheless I have realized that B.MI is
- a lot more coherent and easy to use that I had imagined. This makes me
- think again in the problem. In the design that I am coding now, bimap
- <span class="bold"><strong>is-a</strong></span> multi_index_container specializes
- with a data type very comfortable called bipair, that can be seen like
- any of the two maps that integrates it using map views. This scheme has
- great benefits for users: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - If the user already knows B.MI, he can take advantage of the
- tools that it provides and that are not present in the STL containers.
- In addition, in some cases the use to indices to see the data can be very
- useful. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - If the user does not know anything about B.MI but have an
- STL framework, the learning curve is reduced to understand the bimap instantiation
- and how a is obtained the desired map view. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Another very important benefit holds: All the algorithms done
- for B.MI continues to work with Boost.Bimap and if B.MI continues growing,
- bimap grow automatically. </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> Umm... This is an interesting design decision, but controversial
- in my opinion. Basically you decide to expose the implementation of bimap;
- that has advantages, as you stated, but also a nonsmall disadvantage: once
- <span class="bold"><strong>you have documented</strong></span> the implementation,
- it is not possible to change it anymore. It is a marriage with B.MI without
- the chance of divorce. The other possibility, to hide the implementation
- and to duplicate and document the provided functionality, explicitly or
- implicitly due to the same characteristics of the implementation, is of
- course heavier to maintain, but it gives a degree of freedom to change
- the guts of your software if you need to. Do not take this like a frontal
- objection, but I think that it is quite important design decision, not
- only in the context of bimap but in general. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> You are quite right here. I think we have to choose the hardest
- path and hide the B.MI core from the user. I am sending you the first draft
- of bimap along with some documentation. </em></span>
- </p></blockquote></div>
- <p>
- <code class="literal">- This completes the second week, the documentation was basically
- the first section of this rationale -</code>
- </p>
- <p>
- <span class="bold"><strong>Joaquin</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I must confess that I am beginning to like what I see. I am
- mathematical by vocation, and when I see symmetry in a formulation I believe
- that it is in the right track. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> We are two mathematicians by vocation then. </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 think that the part of std::set theory is very clear. To me,
- it turns out to me somewhat strange to consider the rank of a map (values
- X) like a std::set, but of course the formulation is consistent. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I like it very much, it can be a little odd at first, but now
- that I have get used to it, it is very easy to express in the code my contrains
- on the data, and I believe that if somebody reads the code and sees the
- bimap instantiation he is not going to have problems understanding it.
- Perhaps it is easier to understand it if we use your notation: ordered_nonunique,
- unordered_unique, but this goes against our STL facade. In my opinion the
- user that comes from STL must have to learn as less as possible. </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> Considering a relation like a <code class="computeroutput"><span class="keyword">struct</span>
- <span class="special">{</span><span class="identifier">left</span><span class="special">,</span> <span class="identifier">right</span><span class="special">}</span></code> is clean and clear. If I understand it
- well, one relation has views of type <code class="computeroutput"><span class="identifier">pair</span><span class="special">{</span><span class="identifier">first</span><span class="special">,</span> <span class="identifier">second</span><span class="special">}</span></code>, is this correct? </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Yes, I believe that the left/right notation to express symmetry
- is great. I believe that to people is going to love it. </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> OK, perfect. I likes this very much: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- bm.left is compatible with std::map<A,B></em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- bm.right is compatible with std::map<B,A></em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- bm is compatible with std::set<relation<A,B>></em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> It is elegant and symmetric. I feel good vibrations here. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</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>Joaquin</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Moving on, the support for N-1, N-N, and hashed index is very
- easy to grasp, and it fits well in framework. However I do not finish to
- understand very well the "set<relation> constraints" section.
- Will you came up with some examples of which is the meaning of the different
- cases that you enumerate? </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias - </strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Yes, I mean: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- based on the left</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- based on the right</em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> The bimap core must be based on some index of multi index. If
- the index of the left is of the type hash, then in fact the main view is
- going to be an unordered_set< relation<A,B> >. Perhaps this
- is not what the user prefers and he wants to base its main view on the
- right index. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- set_of_relation </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- multiset_of_relation </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- unordered_set_of_relation </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em>- unordered_multiset_of_relation </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> However, if both of them are hash indexes, the user may want
- the main view to be ordered. As we have a B.MI core this is very easy to
- support, we just have to add another index to it. </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 understand it now. OK, I do not know if we have to include
- this in the first version, is going to be a functionality avalanche! </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> The user is not affected by the addition of this functionality,
- because by default it will be based on the left index that is a very natural
- behaviour. I do not think that this is functionality bloat, but I agree
- with you that it is a functionality avalanche. </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> There are restrictions between the left and right set types
- and the possible main view set types. For example if some of the index
- is of unique type, then the main view cannot be of type multiset_of_relation.
- To the inverse one, if the main view is of type set_of_relation the left
- and the right index cannot be of type multi_set. All this subject of the
- unicity constrictions and the resulting interactions between indexes is
- one of the subtle subjects of B.MI. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> This can be checked at compile time and informed as an error
- in compile time. </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> It can be interesting. </em></span>
- </p></blockquote></div>
- <p>
- <code class="literal">- And right when everything seems to be perfect... - </code>
- </p>
- <p>
- <span class="bold"><strong>Joaquin</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I have some worse news with respect to mutant, it is very a
- well designed and manageable class, unfortunately, C++ does not guarantee
- layout-compatibility almost in any case. For example, the C++ standard
- does not guarantee that the classes <code class="computeroutput"><span class="keyword">struct</span><span class="special">{</span><span class="identifier">T1</span> <span class="identifier">a</span><span class="special">;</span> <span class="identifier">T2</span>
- <span class="identifier">b</span><span class="special">;}</span></code>
- and <code class="computeroutput"><span class="keyword">struct</span><span class="special">{</span><span class="identifier">T1</span> <span class="identifier">b</span><span class="special">;</span> <span class="identifier">T2</span> <span class="identifier">a</span><span class="special">;}</span></code> are
- layout-compatible, and therefore the trick of reinterpret_cast is an undefined
- behavior. I am with you in which that in the 100% of the cases this scheme
- will really work, but the standard is the standard. If you can look the
- layout-compatibility subject in it (http://www.kuzbass.ru/docs/isocpp/).
- As you see, sometimes the standard is cruel. Although mutant seems a lost
- case, please do not hurry to eliminate it. We will see what can be done
- for it. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I read the standard, and you were right about it. Mutant was
- an implementation detail. It is a pity because I am sure that it will work
- perfect in any compiler. Perhaps the standard becomes more strict some
- day and mutant returns to life... We can then try a wrapper around a relation<A,B>
- that have two references named first and second that bind to A and B, or
- B and A. </em></span>
- </p></blockquote></div>
- <p>
- </p>
- <pre class="programlisting"><span class="identifier">relation</span><span class="special"><</span><span class="identifier">TA</span><span class="special">,</span><span class="identifier">TB</span><span class="special">></span> <span class="identifier">r</span><span class="special">;</span>
- <span class="identifier">const_reference_pair</span><span class="special"><</span><span class="identifier">A</span><span class="special">,</span><span class="identifier">B</span><span class="special">></span> <span class="identifier">pba</span><span class="special">(</span><span class="identifier">r</span><span class="special">);</span>
- <span class="identifier">const_reference_pair</span><span class="special"><</span><span class="identifier">B</span><span class="special">,</span><span class="identifier">A</span><span class="special">></span> <span class="identifier">pbb</span><span class="special">(</span><span class="identifier">r</span><span class="special">);</span>
- </pre>
- <p>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> It is not difficult to code the relation class in this way but
- two references are initialized with every access and the use of <code class="computeroutput"><span class="identifier">pba</span><span class="special">.</span><span class="identifier">first</span></code> will be slower than <code class="computeroutput"><span class="identifier">r</span><span class="special">.</span><span class="identifier">left</span></code>
- in most compilers. It is very difficult to optimize this kind of references.
- </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> This workaround is not possible, due to technical problems with
- the expected behavior of the iterators. If the iterators of bm.left are
- of bidirectional type, then standard stated that it have to return an object
- of type const value_type& when dereferenced. You will have to return
- a const_reference_pair created in the flight, making it impossible to return
- a reference. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I understand... I have workaround for that also but surely the
- standard will attack me again! We must manage to create the class relation
- that responds as we want, the rest of the code will flow from this point.
- This clear separation between the relation class and the rest of the library,
- is going to help to us to separate the problems and to attack them better.
- </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> What workaround? It already pricks my curiosity,I have dedicated
- a long time to the subject and I do not find any solution except that we
- allow the relation class to occupy more memory. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> We must achieve that the relation<A,B> size equals the
- pair<A,B> size if we want this library to be really useful. I was
- going to write my workaround and I realized that It does not work. Look
- at this: http://www.boost.org/libs/iterator/doc/new-iter-concepts.html
- Basically the problem that we are dealing is solved if we based our iterators
- on this proposal. The present standard forces that the bidirectional iterators
- also are of the type input and output. Using the new concepts there is
- no inconvenient in making our iterators "Readable Writable Swappable
- Bidirectional Traversal". Therefore the const_reference_pair returns
- to be valid. </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> It is correct in the sense that you simply say that your iterators
- are less powerful than those of the std::map. It is not that it is wrong,
- simply that instead of fixing the problem, you confess it. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> OK, but in our particular case; What are the benefits of offering
- a LValue iterator against a Read Write iterator? It does not seem to me
- that it is less powerful in this case. </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> The main problem with a ReadWrite is that the following thing:
- <code class="computeroutput"><span class="identifier">value_type</span> <span class="special">*</span>
- <span class="identifier">p</span><span class="special">=&(*</span><span class="identifier">it</span><span class="special">);</span></code>
- fails or stores a transitory direction in p. Is this important in the real
- life? I do not know. How frequently you store the direction of the elements
- of a map? Perhaps it is not very frequent, since the logical thing is to
- store the iterators instead of the directions of the elements. Let us review
- our options: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 1. We used mutant knowing that is not standard, but of course
- it is supported in the 100% of the cases. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 2. We used const_reference_pair and we declared the iterators
- not LValue. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 3. We found some trick that still we do not know. I have thus
- been playing with unions and things, without much luck. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 4. We leverage the restriction that views have to support the
- first, second notation. If we made this decision, there are several possibilities:
- </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> a. The left map has standard semantics first/second while the
- right map has the inverse semantics. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> b. Instead of first and second we provide first() and second(),
- with which the problem is trivial. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> c. The map view do not support first/second but left/right as
- the father relation </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 5. We solve the problem using more memory than sizeof(pair<A,B>).
- </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> In any case, I would say that the only really unacceptable option
- is the last one. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Lets see. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 1. I want the "standard compliant" label in the library.
- </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 2. This is the natural choice, but knowing that there is another
- option that always works and it is more efficient is awful. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 3. I have also tried to play with unions, the problem is that
- the union members must be POD types. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 4. This option implies a big lost to the library. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 5. Totally agree. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I want to add another option to this list. Using metaprogramming,
- the relation class checks if the compiler supports the mutant idiom. If
- it supports it then it uses it and obtains zero overhead plus LValue iterators,
- but if it do not supports it then uses const_reference_pair and obtains
- minimum overhead with ReadWrite iterators. This might be controversial
- but the advantages that mutant offers are very big and the truth is that
- I do not believe that in any actual compiler this idiom is not supported.
- This scheme would adjust perfectly to the present standard since we are
- not supposing anything. The only drawback here is that although the mutant
- approach allows to make LValue iterators we have to degrade they to Read
- Write in both cases, because we want that the same code can be compiled
- in any standard compliant compiler. </em></span>
- </p></blockquote></div>
- <p>
- <code class="literal">- Hopefully we find our way out of the problem -</code>
- </p>
- <p>
- <span class="bold"><strong>Joaquin</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Changing the subject, I believe that the general concept of
- hooking data is good, but I do not like the way you implement it. It has
- to be easy to migrate to B.MI to anticipate the case in that Boost.Bimap
- becomes insufficient. It is more natural for a B.MI user that the data
- is accessed without the indirection of <code class="computeroutput"><span class="special">.</span><span class="identifier">data</span></code>. I do not know how this can be articulated
- in your framework. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> I have a technical problem to implement the data_hook in this
- way. If the standard would let us use the mutant idiom directly, I can
- implement it using multiple inheritance. But as we must use const_reference_pair
- too, It becomes impossible for me to support it. We have three options
- here: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 1) relation { left, right, data } and pair_view { first, second,
- data } </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - This is more intuitive within the bimap framework, since it
- does not mix the data with the index, as a table in a data base does, but
- gives more importance to the index. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - It is not necessary that the user puts the mutable keyword
- in each member of the data class. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - This moves away just a little bit from B.MI because the model
- of it is similar to a table, but it continues to exist a clear path of
- migration. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 2) relation { left,right, d1,d2... dn } and pair_view { first,
- second, data } </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - The path to B.MI is the one you have proposed. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - It is very asymmetric. It is necessary to explain that the
- views are handled different that the relation. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - The user must place the mutable keyboards in the data class.
- </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 3) Only relation { left,right, d1,d2... dn } </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - Simple migration path to B.MI. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> - You are not able to access the hooked data from the views.
- </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> My vote goes to the first 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> Yes, the first option is the one that less surprises hold to
- the user. I also vote for 1. </em></span>
- </p></blockquote></div>
- <p>
- <code class="literal">- The third week was over -</code>
- </p>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> There is still one problem that I have to solve. I need to know
- if it is necessary to create a map_view associated to nothing. If it is
- necessary there are two options: that it behaves as an empty container
- or that it throws an exception or assert when trying to use it. If it is
- not necessary, the map_view is going to keep a reference instead of a pointer.
- To me, the map_view always must be viewing something. In the case of the
- iterators being able to create them empty, makes them easy to use in contexts
- that require constructors by default, like being the value_type of a container,
- but I do not believe that this is the case of map_view. </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> How would an empty map_view be useful? My intuition is like
- yours, map_view would have to be always associate to something. If we wished
- to obtain the semantics "is associated or not" we can use a pointer
- to a map_view. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> OK, then you agree to that map_views stores a reference instead
- of a pointer? </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> It depends on the semantics you want to give to map_views, and
- in concrete to the copy of map_views. </em></span>
- </p></blockquote></div>
- <p>
- </p>
- <pre class="programlisting"><span class="identifier">map_view</span> <span class="identifier">x</span><span class="special">=...;</span>
- <span class="identifier">map_view</span> <span class="identifier">y</span><span class="special">=...;</span>
- <span class="identifier">x</span><span class="special">=</span><span class="identifier">y</span><span class="special">;</span>
- </pre>
- <p>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> What is supposed to do this last line? </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 1. Rebinding of x, that is to say, x points at the same container
- that y. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 2. Copy of the underlying container. </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> If you want to implement 1, you cannot use references internally.
- If you want to implement 2, it is almost the same to use a reference or
- a pointer. </em></span>
- </p></blockquote></div>
- <p>
- <span class="bold"><strong>Matias</strong></span>
- </p>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> If I want that they behave exactly as std::maps then I must
- go for 2. But if I think they as "views" of something, I like
- 1. The question is complicated. I add another option: </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> 3. Error: operator= is declare as private in boost::bimap::map_view
- std_container </em></span>
- </p></blockquote></div>
- <div class="blockquote"><blockquote class="blockquote"><p>
- <span class="emphasis"><em> Also What happens with <code class="computeroutput"><span class="identifier">std_container</span>
- <span class="special">=</span> <span class="identifier">view</span><span class="special">;</span></code>? and with <code class="computeroutput"><span class="identifier">view</span>
- <span class="special">=</span> <span class="identifier">std_container</span><span class="special">;</span></code>? </em></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-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="code.html"><img src="../../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../rationale.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="../history.html"><img src="../../../../../../doc/src/images/next.png" alt="Next"></a>
- </div>
- </body>
- </html>
|