<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.75.2">
<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<span class="emphasis"><em>isocpp</em></span>).
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 -2007 Matias Capeletto<p>
Distributed under the Boost Software License, Version 1.0. (See accompanying
file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>)
</p>
</div></td>
</tr></table>
<hr>
<div class="spirit-nav">
<a accesskey="p" href="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>
