In 2/26/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Matias Capeletto wrote:
On 2/25/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> 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/rationa... Comments about it are welcome, this is one of the difficult points of the library. Matias