devn00b
/
EQ2EMu


			
				
					
						
						
							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&#160;1.&#160;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&lt;A,B&gt;</em></span>
        </p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>- bm.right is compatible with std::map&lt;B,A&gt;</em></span>
        </p></blockquote></div>
<div class="blockquote"><blockquote class="blockquote"><p>
          <span class="emphasis"><em>- bm is compatible with std::set&lt;relation&lt;A,B&gt;&gt;</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&lt;relation&gt; 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&lt; relation&lt;A,B&gt; &gt;. 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&lt;A,B&gt;
          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">&lt;</span><span class="identifier">TA</span><span class="special">,</span><span class="identifier">TB</span><span class="special">&gt;</span> <span class="identifier">r</span><span class="special">;</span>
<span class="identifier">const_reference_pair</span><span class="special">&lt;</span><span class="identifier">A</span><span class="special">,</span><span class="identifier">B</span><span class="special">&gt;</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">&lt;</span><span class="identifier">B</span><span class="special">,</span><span class="identifier">A</span><span class="special">&gt;</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&amp; 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&lt;A,B&gt; size equals the
          pair&lt;A,B&gt; 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">=&amp;(*</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&lt;A,B&gt;).
          </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 &#169; 2006-2012 Matias Capeletto<p>
        Distributed under the Boost Software License, Version 1.0. (See accompanying
        file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
      </p>
</div></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="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>