On 2/25/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Matias Capeletto wrote:
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
Maybe I have introduce noise here. The left view is the bidirectional mapping 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