Boost logo

Boost :

From: Daryle Walker (darylew_at_[hidden])
Date: 2007-07-17 14:24:46

I was checking out the BiMap docs at
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at