Re: [boost] [Review][bimap]

From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2007-02-26 11:33:41

In 2/26/07, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
> Matias Capeletto wrote:
> > On 2/25/07, Thorsten Ottosen <thorsten.ottosen_at_[hidden]> wrote:
>
> >>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.
>
> Oh, that's bad. Another consequence of not using the same underlying
> pair type.

Yes, but this problem is there independently of the using of left/right in the
right view because in it the pair members are inverted. Do you think it will be
better that the right view has X as first and Y as second, this will
not allow us
to use it like a std::map<Y,X>.

> > 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.
>
> I'm somewhat uncomfortable about this casting. Is it provable legal by
> the standard? (What works fine for pair<int,int>, might crash for
> pair<Foo,Bar>.)

Yep... the reinterpret cast works in almost every actual compiler. It
uses a non standard feature. It assumes that:

struct Pair_AB { TA first; TB second; };

have the same structure that

struct Pair_BA { TB first; TA second; };

In the standard this is true if TA and TB are POD types.
But in the real world this is generally implemented this way for non
POD types too.
In boost/bimap/relation/relation.cpp the library checks if it can use
the mutant_relation for the types in question and if not it uses a
standard_relation, that is implemented using references to the types.
It is impossible to achieve zero overhead performance over
Boost.MultiIndex if the mutant_relation is not supported.

This is explained here:
http://cablemodem.fibertel.com.ar/mcape/boost/libs/bimap/boost_bimap/rationale.html#boost_bimap.rationale.general_design.relation_implementation

Comments about it are welcome, this is one of the difficult points of
the library.

Matias