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
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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk