I was checking out the BiMap docs at <http://cablemodem.fibertel.com.ar/mcape/oss/projects/mc_projects/boost_projects/boost_bimap.html>, especially the Doxygen information about the classes. I was thinking that BiMap looked complicated, and something about that bothered me. When I read BiMap's history, especially its relation to MultiIndex, I figured out what could be wrong: BiMap is too much an exemplar of MultiIndex. The interface of BiMap has a lot of features that showcase the fact that it was built using MultiIndex. The tagging interface for alternative names for "left" and "right" and the ability to specify the indexing philosophy (set, map, hash, list, vector) for the sides and the container as a whole (a.k.a. "set type of relation") seem like big cases of You Aren't Going To Need It. The STL maps don't give this kind of customization, maybe because it isn't necessary. If you don't like the names "left" and "right," just use new names in whatever class you'll be wrapping the bimap around. Specifying indexing strategies just limits how the bimap can be internally constructed, possibly limiting efficiency. There is also a lot of exposed template meta-programming (something complained about in a recent SlashDot thread). The main template interface even uses it (to let the user exclude one or both comparison types while still specifying an allocator)! What's wrong with: //================================================================== enum link_modes { one_and_one, one_and_many, many_and_one, many_and_many }; template < typename LeftT, typename RightT, link_modes LinkMode, typename CompareL = ::std::less<LeftT>, typename CompareR = ::std::less<RightT>, class Allocator = ::std::allocator< ::std::pair<LeftT, RightT> > > class bimap; //================================================================== (There's no tagging or index-specifying because YAGTNI. There's also no "politically correct" substitute for std::pair.) You don't just use the interface as if it was straight-forward, it actually is straight-forward. That means that there's less to go wrong. Sometimes as a developer, you have to Just Say No to 15 billion points of customization, even if the internal pieces allow them. Design an optimal interface for BiMap first, then see how a MultiIndex can help in the implementation, even if the multi-index ends up being hidden (or not used at all!); don't design with the priorities reversed. (It's a little late for BiMap, but maybe whoever does the MRU [most recently used] idea should take this into account.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com