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

Thorsten Ottosen wrote:

Jeff Garland wrote:

...

Thorsten Ottosen wrote:

...

...

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

My concerns where also with keys that can be *implicitly* converted to eachother, say, int and unsigned.

Oh yes, that's a good point. I think I'm in agreement now -- that interface is probably just too dangerous.

...

1) change name of mbimap_one_to_many --> perhaps multi_bimap_1_to_m

FWIW, I think bimap and bimultimap make a good basis. This would allow for bimap_1_to_m and bimultimap_1_to_m

Yep, even better. Wonder if spelling it out a bit more would be even clearer. bidirectional_map_1_to_m bidirectional_multimap_m_to_m seems a bit too much, while bidir_map_1_to_m bidir_multimap_m_to_m seems about right. Jeff