Re: [boost] [bimap] Too much multi-index in interface?

From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2007-07-23 00:14:16

Hi Daryle, sorry for the delay, it was a busy week.

On 7/17/07, Daryle Walker <darylew_at_[hidden]> wrote:
> 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.

The doxygen docs are not part of the user docs... they are intended
for developers trying to understand the guts of Boost.Bimap.

> I was thinking that BiMap looked complicated,

I prefer the word complex :)

> and something about that bothered me.

Simple things are better, I agree.

> 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.

Strong comment.

> 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.

If you do not want to use that features you just ignore them. A great
effort was put in making simple use cases simple, and allow to easily
cope with complex cases.

I can not think of a simpler declaration for a Bimap than:

  boost::bimap<X,Y> bm;

You can simple ignore the possibility of using tags, or the
flexibility that bimap offers to you by allowing you to select what
kind of collection you will use for each side.

> 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.

I do not follow you here. A bimap is not a wrap around a class.

> Specifying indexing strategies just limits
> how the bimap can be internally constructed, possibly limiting efficiency.

???
STL maps:

  std::map<X,Y>
  std::multimap<X,Y>
  std::unordered_map<X,Y>
  std::unordered_multimap<X,Y>
  std::vector< pair<X,Y> >
  std::list< pair<X,Y> >

They offer you exactly the same kind of customization, only that for
one side of the mapping.

> There is also a lot of exposed template meta-programming (something
> complained about in a recent SlashDot thread).

Please tell me you are not taking SlashDot as a reference.

> 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.

Can I use existent algorithms with your design?
Can I print the reverse map with a standard based print_map function?

Like this:

   print_map( bm.left );    // It works
   print_map( bm.right );  // It works too!

> 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.)

We make a big effort to do exactly this. I think that Bimap is influenced by
MultiIndex, but it is independent of it.

Do you know that you can use Boost.Bimap with out reading
Boost.MultiIndex docs?

I do not think that Boost.Bimap is bloated, it offers a very simple interface
for simple cases, and let you customize it for complex problems.

Thanks for the feedback!
Please keep coming with more :)

Best regards
Matias