[multi_index_container] Using equal_range with hashed indices
Hello! std::equal_range requires that the container be pre-sorted ( http://www.cplusplus.com/reference/algorithm/equal_range/) How does multi-index container handle this scenario with respect to hashed non-unique indices. The reason I ask is since I'm facing a situation with equal_range. Please see below code - typedef bmi< UserIdEntry, indexed_by< hashed_non_unique<tag<id1_id2>, composite_key<UserIdEntry, BMI_MEMBER(UserIdEntry, std::string, id1), BMI_MEMBER(UserIdEntry, std::string, id2) > > >
UserIdContainer;
typedef UserIdContainer::index<id1_id2>::type IndexById1Id2; typedef IndexById1Id2::const_iterator IndexById1Id2_it; std::pair<IndexById1Id2_it, IndexById1Id2_it> entries = indexById1Id2.equal_range(make_tuple(id1_val, id2_val)); I'm seeing that *sometimes* entries.first equals indexById1Id2.end() and entries.second does not equal indexById1Id2.end(). The lookup is valid - meaning I've verified that there is at-least one entry which should be caught by the equal_range. I'm guessing the iterators' values are swapped. (second should be pointing to first and first should be pointing to second) What could be the reason for this? Thanks, MK.
Muruganand Karthikeyan <muruthegun <at> gmail.com> writes:
Hello!
std::equal_range requires that the container be pre-sorted (http://www.cplusplus.com/reference/algorithm/equal_range/) How does multi-index container handle this scenario with respect to hashed non-unique indices.
Hashed indices' equal_range works on sequences that have no particular order (other than equivalent elements being adjacent), which is fine because it does *not* use std::equal_range internally but its own logic (much as, say, std::unordered_set::equal_range).
The reason I ask is since I'm facing a situation with equal_range. Please see below code -
[...] typedef UserIdContainer::index<id1_id2>::type IndexById1Id2; typedef IndexById1Id2::const_iterator IndexById1Id2_it; std::pair<IndexById1Id2_it, IndexById1Id2_it> entries = indexById1Id2.equal_range(make_tuple(id1_val, id2_val));
I'm seeing that *sometimes* entries.first equals indexById1Id2.end() and entries.second does not equal indexById1Id2.end(). The lookup is valid - meaning I've verified that there is at-least one entry which should be caught by the equal_range.
A range [a,b) where a==end and b!=end is invalid. As far as I can see, this means that * Your code has somehow broken the internals of the container, * or Boost.MultiIndex has a bug. Can you isolate one case where you observe the anomalous behavior into a complete test snippet I can take a look at? Thank you Joaquín M López Muñoz Telefónica
participants (2)
-
Joaquin M López Muñoz -
Muruganand Karthikeyan