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
>> Your URL isn't quite right -- it's missing an soc
> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk