On 7/30/14, 5:17pm, Joaquin M Lopez Munoz wrote:
Absolutely. The interface of hashed indices is modelled upon that of C++ unordered associative containers. equal_range(3) (on the MSB index) will get you the elements you're after.
Perfect! So I am doing something wrong with a library that does what I'd
like!
The following is a simple dump & append to list. The objective is
simple, append to a list all 128-bit integers that have a common MSB. To
debug I've also dumped the whole container, just to be sure.
My code, actually, won't find anything with equal_range, and find will
return 0, although my call works in some sense, or better, the element I
am passing DOES exist in the container. Source and output in the following.
Apart from feeling shame over my flawed code, I'd like to know some
underlying facts, if possible.
The complexity of equal_range is constant with respect to the key I'm
finding, in other words, linear wrt the number of matched keys. Is this
always the average case regardless of the number of elements in the
container?
If I need to find, for instance, all items matching MSB, and within
them, all matching HSB, will I need an additional key (composite key, if
I understand)? It seems quite expensive from the memory point of view,
so in case I have may items I could just iterate over them.
Instead of copying matched items, is it possible to have a
"sub-container" akin to a view, without copying anything? Probably not...
Thanks for your valuable help!
Cheers!
=== SOURCE ===
typedef boost::multi_index::multi_index_container<
__uint128_t,
boost::multi_index::indexed_by<
boost::multi_index::ordered_non_unique