Jeff Garland wrote:

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 It is one of my goals

...

...

...

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

Noted.

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.

It is possible that the ambiguity can be detected at compile time with metaprogramming (is_convertible, etc) and disable part of the interface. Then the user has to use bimap.to or bimap.from

...

...

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

The name definitively is subject to change. Thanks for the comments, Adrián Etchevarne.