Hi Daryle, sorry for the delay, it was a busy week. On 7/17/07, Daryle Walker <darylew@hotmail.com> 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