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
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 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
> seems a bit too much, while
> seems about right.
The name definitively is subject to change.
Thanks for the comments,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk