Matias Capeletto wrote:
In 2/26/07, Thorsten Ottosen <thorsten.ottosen@dezide.com> wrote:
Matias Capeletto wrote:
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 was actually thinking that the views merely stored references. Reading on, it seems like that is what you do.
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.
I'm certainly confused here. What do you mean by "same structure"? If you had written struct Pair_BA { TA first; TB second; }; I might have understood it.
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.
Right. How it sucks that std::pair did not go for reference returning functions instead of members!. What if you make the members of the view pairs something like template< class Pair& > struct get_first { Pair& p_; operator typename Pair::first_type&() const { return p_.first; } }; ? -Thorsten