[bimap] relation information (was: [multi_index] User-defined indices)
On 6/10/07, Andrey Semashev <andysem@mail.ru> wrote: Hi andrey
Exactly.
What is the value_type of the container then?
Why is that important to you? Even when you do not use additional information the value type of the container is an implementation detail. But that's is why value_type exists. You do no have to worry about the implementation type.
What are the names of the two keys and info in it?
In this bimap: bm::left_map::value_type (signature-compatible to std::pair<left_type,right_type>) ---------------------------------- first : is the left element that acts as the key second : is the right element that acts as the data info : is the information, that do not participate in the map bm::right_map::value_type (signature-compatible to std::pair<right_type,left_type>) ---------------------------------- first : is the right element that acts as the key second : is the left element that acts as the data info : is the information, that do not participate in the map bm::value_type ---------------------------------- first : is the right element second : is the left element info : is the information, that do not participate in the map
I do not see a problem here.
Obscure names of value_type members,
They are not obscure.
an dependency on bimap are very undesirable.
Ok that is your call :) If you want to give your users better names you can use tags: struct wildcard_string {}; struct id {}; struct fancy_info_name {}; typedef bimap< set_of< tagged<string, wildcard_string>, WildcardOrder>, unordered_set_of< tagged< int, id > >, with_info< tagged< MyInfo, fancy_info_name > > bm_type; bm_type bm; ... cout << bm.by<id>.find(2)->get<wilcard_string>() I am not saying that a bimap is better than a multi_index_container here. I just want to point out that you "can" use it if you want. Best Regards Matias Bimap online docs: http://tinyurl.com/22sja5
Hello Matias, Sunday, June 10, 2007, 6:47:18 PM, you wrote:
On 6/10/07, Matias Capeletto <matias.capeletto@gmail.com> wrote:
bm::value_type
Today is definitely not my day... lets try one last time:
As I've said, there are two problems with these: 1. bm::value_type is dependent on bm which is both Boost.Bimap and my component implementation detail. I don't want to put that dependency on the user's code. 2. left, right and info members are not self-explaining to users. There is no left or right side of my component. This might be better if bimap allowed to express relations between opaque structure members, something like: struct MyData { std::string Wildcard; unsigned int ID; std::string Rule; int Whatever; }; typedef bimap< set_of< string, WildcardOrder >, unordered_set_of< unsigned int >, contains< MyData, left_is< MyData, string, &MyData::Wildcard >, right_is< MyData, unsigned int, &MyData::ID >
MyBimap_t;
But I guess, that leads us to Boost.MultiIndex.
Very sorry :(
Don't mention, it happens. :) -- Best regards, Andrey mailto:andysem@mail.ru
Hello Matias, Sunday, June 10, 2007, 6:41:37 PM, you wrote:
On 6/10/07, Andrey Semashev <andysem@mail.ru> wrote:
Hi andrey
[snip]
What is the value_type of the container then?
What are the names of the two keys and info in it?
[snip]
I do not see a problem here.
Obscure names of value_type members,
They are not obscure.
Well, they tell nothing about their purpose. That's what I always disliked about std::pair - the expression v.second doesn't tell you anything. And v.left or v.right don't make it better, especially assuming that my component doesn't express any such symmetry. v.Mask or v.ID are much more telling in the user's code. [snip]
I am not saying that a bimap is better than a multi_index_container here. I just want to point out that you "can" use it if you want.
Aside naming and dependency issues, I see bimap is based on the Boost.MultiIndex. I showed I can't use B.MI for my case because of its requirements on functors. Does bimap change B.MI's requirements on them? If not, I don't see how it is better in this way. Anyway, thank you for your helping efforts. I'm sure bimap has its field of use, but I'm afraid it's not the case. -- Best regards, Andrey mailto:andysem@mail.ru
participants (2)
-
Andrey Semashev -
Matias Capeletto