Re: [boost] Another proposal for Bimap and Boost.MultIndex

From: Jeff Garland (jeff_at_[hidden])
Date: 2006-05-07 11:51:49

Thorsten Ottosen wrote:
> Hi Adrian,
> 
> Jeff Garland wrote:
>> Adrián Etchevarne wrote:
>>
>>> Hello boosters, 
>>>
>>> I am submitting a proposal to Summer of Code of Google, and I am asking for  
>>> some opinions about it.
>>> If you are intereste you can reach it at
>>>
>>> http://termovirtual.homeunix.org/~saknussemm/SoCGoogle.pdf
>>> http://termovirtual.homeunix.org/~saknussemm/SoCGoogle.ps.gz
>>
>> Your URL isn't quite right -- it's missing an soc
>>
>> http://termovirtual.homeunix.org/~saknussemm/soc/SoCGoogle.pdf
> 
> Here are some comments on the interface/paper.
> 
> - you call it bitmap<K,V> somewhere, should be bimap, I expect

Yep, that's in the title and a number of other places.

> - I would srongly consider making the interface a refinement of std::map 
> to allow drop in-replacement, and to minimize surprises for people
> 
> - Letting operator[]() work with Key1 and Key2 seems like a bad thing: 
> what if the types are the same? What if the types are implicitly 
> convertible to eachother (seems error-prone).

It seems like a nice convenience in the case where the key and the value 
are different.  I think it would be fine if it's documented in bold 
print in the docs. Certainly it creates is for the cut/paste programmers 
that just try to follow an existing example with different key types and 
then change it to be the same.

> - if possible, prerserve the semantics of std::map<K,V>::operator[]() 
> and provide throwing behavior by an at() member.
> 
> - consider not having to/from, but to have
> 
>      find( const Key1& );
>      find2nd( const Key2& );
>      at( const Key& );
>      at2nd( const Key& );
>      ...

I might have to disagree with this -- I like to/from better.  But it's a 
detail we can argue about ;-)

---
Couple other thoughts:
1) change name of mbimap_one_to_many --> perhaps multi_bimap_1_to_m
2) change name mbimap_many_to_many --> perhaps multi_bimap_m_to_m
3) 1.2.6 Hash --> you say I can use hashes to store the keys, but 
there's no detail on how that would work?  Do I declare the collection 
differently or something?
4) Will these containers automagically get serialization support because 
they are based on MI?   In any case I'd like to see serialization 
support and documentation thereof.
Overall, this looks really good!
Jeff