c++ boost::multi_index composite keys efficiency

清泛网

Long time reader first time poster! I'm playing around with the boost::multi_index container stuff and have a rather in-depth question that hopefully a boost or C++ container expert might know (my knowledge in C++ containers is pretty basic). For reference, the boost documentation on composite keys can be found here: boost::multi_index composite keys.

When using a composite key, the documentation states that "Composite keys are sorted by lexicographical order, i.e. sorting is performed by the first key, then the second key if the first one is equal, etc". Does this mean that the structure is stored such that a lookup for a specific 2-part composite key will take O(n=1) time, i.e. is the container sorted such that there is a pointer directly to each item, or does the boost container retrieve a list that matches the first part of the composite key and then need to perform a search for items matching the second part of the key and thus is slower?

For example, if I was to maintain two containers manually using two different indices and wanted to find items that matched a specific 2-part query I would probably filter the first container for all items matching the 1st part of the query, and then filter the result for items that match the 2nd part of the query. So this manual method would effectively involve two searches. Does boost effectively do this or does it improve on efficiency somehow via the use of composite keys?

Hopefully I've explained myself here but please ask questions and I will try my best to clarify exactly what I mean!

From：http://stackoverflow.com/questio ... ite-keys-efficiency

清泛网

Lookups involving composite keys do not go through any two-stage process as you describe. composite_key-induced orderings are normal orderings, the only special thing about it being its dependence on two or more element keys rather than one.

Maybe an example will clarify. Consider this use of composite_key:

1. struct element
   
2. {
   
3.   int x,y,z;
   
4. };
   
5. 
   
6. typedef multi_index_container<
   
7.   element,
   
8.   indexed_by<
   
9.     ordered_unique<
   
10.       composite_key<
    
11.         element,
    
12.         member<element,int,&element::x>,
    
13.         member<element,int,&element::y>,
    
14.         member<element,int,&element::z>
    
15.       >
    
16.     >
    
17.   >
    
18. > multi_t;

复制代码

The resulting container is in a sense equivalent to this:

1. struct element_cmp
   
2. {
   
3.   bool operator()(const element& v1, const element& v2)const
   
4.   {
   
5.     if(v1.x<v2.x)return true;
   
6.     if(v2.x<v1.x)return false;
   
7.     if(v1.y<v2.y)return true;
   
8.     if(v2.y<v1.y)return false;
   
9.     return v1.z<v2.z;
   
10.   }
    
11. };
    
12. 
    
13. typedef std::set<element,element_cmp> set_t;

复制代码

composite_key automatically generates equivalent code to that in element_cmp::operator(), and additionally allows for lookup on just the first n keys, but the underlying data structure does not change with respect to the case using std::set.