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

From: Adrián Etchevarne (adrian.etchevarne_at_[hidden])
Date: 2006-05-07 16:10:05

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.