Re: [boost] [Review][bimap]

From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2007-02-25 23:10:45

On 2/25/07, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
> Matias Capeletto wrote:
>
>>> Maybe I have introduce noise here. The left view is the
> bidirectional mapping
>  >>> view from the left, the one obtained with bm.left
>  >>>
>  >>> bimap<X,Y>::left_map_type is signature compatible with std::map<X,Y>.
>  >>> bimap<X,Y>::left_map_type::value_type is signature-compatible with
>  >>> std::pair<X,Y> and
>  >>> bimap<X,Y>::right_map_type::value_type is signature-compatible with
>  >>> std::pair<Y,X>
>  >>>
>  >>> So you can use this view or the right one with generic algorithms
> that need
>  >>> first/second members.
>  >>
>  >>
>  >> I missed that. It seems like there is less to worry about then :-)
>  >
>  >
>  >
>  >> Take this example:
>  >>
>  >>
>  >>     typedef bimap<std::string,int> results_bimap;
>  >>     typedef results_bimap::relation position;
>  >>
>  >>     results_bimap results;
>  >>     results.insert( position("Argentina"    ,1) );
>  >>     results.insert( position("Spain"        ,2) );
>  >>     results.insert( position("Germany"      ,3) );
>  >>     results.insert( position("France"       ,4) );
>  >>
>  >>
>  >> I could not find any documentation on direct members of
>  >> a bimap. Should it read results.left.insert()???
>  >
>  >
>  >
>  > No, there is some confusion here. The documentation will have to be
>  > changed to help grasp the essence of bimap easier. Fernando Cacciola
>  > has proposed some useful changes to the docs.
>
>
> I looked in the reference section under bimap and it only stated
> constructors and types. Have I found some old documentation on the net
> somehow?

No. In that page of the reference it is state in the code box that the
bimap class is derived from a set of relation view. Each set of
relation is documented in the next sections because they are have
almost exactly the same interface that the maps, except for the
value_type and some typedefs and functions. Each function that is only
valid for maps said that in the docs. I was trying to keep the docs
from getting to big, but maybe it will be better if we have separate
docs for the maps and the sets.

> Anyway, I think I get it.

I have started a thread so we can all talk together about this and the
first/second left/right issue.

>  >> std::make_pair() aside, you are often forced to
>  >> constructing a pair object, only to copy its data once again upon
>  >> insertion into the map.
>  >
>  > Can you give an example?
>
> Well, the rvalue position objects created above is a good example:
>
> 1. creare rvalue string (non-trivial) and int (trivial) arguments
> 2. copy string and int in position constructor
> 3. upon insertion, copy string and int again
>
> So the above takes
>
> 1 constructor call
> 2 copy-constructor calls
>
> per argument, Removing 1 copy-constructor call is the goal here.

I understand.
The problem is bigger in the side views because another copy
construction is taking place. From the inserted pair to relation, and
then to the stored relation inside Boost.MultiIndex.
I think I can change the current implementation to avoid the first
conversion if the compiler support the mutant_relation (you can read
about this in the rationale), because a reinterpret_cast can be used
to convert between bimap pairs and relation. In general
mutant_relation is supported.
But your copy constructor call will continue to be there. I really do
not know how to get ride of it.

Regards
Matias