Re: [Boost-users] [bimap] Creating a bimap fom a std::map

Subject: Re: [Boost-users] [bimap] Creating a bimap fom a std::map
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-11-25 16:08:43

Matias Capeletto wrote:
> On Wed, Nov 25, 2009 at 1:24 PM, Edward Diener <eldiener_at_[hidden]> wrote:
>> Matias Capeletto wrote:
>> My opinion is that you should have a constructor which takes a std::map,
>> where the types of the map are the types of the bimap. If the types of the
>> map are the same as the types of the bimap, then the constructor should do
>> exactly the equivalent to what you show just above. If the types of the map
>> are the reverse of the types of the bimap, then the constructor should be
>> the equivalent of:
>>
>> std::map<std::string,int> myMap;
>> // ... fill myMap
>> boost::bimap<int,std::string> myBimap;
>> myBimap.right.insert(myMap.begin(),myMap.end());
>>
>> This is an ease of use issue and I really do not see why you can not make
>> the use of bimap easier to use in this way. Especially since you also agree
>> that this is a very common scenario.
> 
> I understand your easy-of-use point, but you have just wrote down here
> why it is not a good idea to provide this constructor. Not only it
> breaks the symmetry, the real problem is that following your idea of
> automatic conversion between pairs and relations we bump into
> ambiguities. Imagine you now have a bimap<A,A>, and you use your
> constructor with a map<A,A>... it is not clear which side is the left
> and which side is the right.

Are you saying that if I insert map items on the left side of a bimap I 
can not access them from the right side of the bimap, or vice versa ? 
That would seem to make the bimap fairly useless. If not, in your 
example of bimap<A,A> and map<A,A> it should make no difference whatever 
into which side the map pairs are originally inserted.

> I thought about this issues and it was
> decided that it is better not to surprise the user with this kind of
> ambiguities.
> Thanks for your suggestion and interest.