Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at