JOAQUIN LOPEZ MU?Z wrote:
Just to bring this issue forward to the list, let me state the problem in simple terms. Currently, Boost.Bimap is relying on the following three classes being layout-compatible for the same choice of arguments X and Y (actual names do not match those used inside B.B):
template<typename X,typename Y> struct relation { X left; y right; };
template<typename X,typename Y> struct pair_by_left { X first; Y second; };
template<typename X,typename Y> struct pair_by_right { X second; Y first; };
Assuming layout compatibility allows us to "see" the elements of a bimap as pair_by_left's in the left view and pair_by_right's in the right view, thus matching the (first=key,second=data) syntax of a regular std::map. Needless to say all C++ compilers we know of do in fact provide such a layout compatibility. If we adhered strictly to the C++ standard, this kind of mirroring could only be achieved with non-zero overhead --for instance, holding references to left and right properly named "first" and "second" accordingly to the view.
If I'm not wrong B.B assumes layout compatibility by default but can decay to a standard compliant solution for those (as of yet unknown) compilers where it could be needed.
What do others think about this issue?
Hmmm, if those classes are POD's then layout compatibilty is guarenteed, otherwise it's an assumption. Can it be verified with asserts or static_asserts ? John.