One final suggestion :) regarding the choice of index_container in terms of performance, memory requirements, serialization support and insert/lookup opreations considering that std::vector<const std::string> will be the basis for this container : 1.Composite keys and hashed indices. 2.Hashed indices. Thanks a lot for clarifying all the doubts. -- regards, Prashant Thakre ----- Original Message ----- From: "Joaquín Mª López Muñoz" <joaquin@tid.es> Newsgroups: gmane.comp.lib.boost.user Sent: Thursday, June 08, 2006 6:51 PM Subject: Re: [multi index].[composite key] Index creation at run-time. Prashant Thakre ha escrito:

Hi,

...

OK, here, instead of a composite_key instantiation, you can take advantage directly of std::vector comparison semantics (you don't really need tuple_element):

typedef multi_index_container< element, indexed_by< hashed_unique< member<element,std::vector<const std::string>,&element::tp> > // other indices, maybe

...

element_collection;

Is this equivalent to having a member std::string tp which is constructed at run-time from all the elements of std::vector< const std::string > ?

Depends on how you construct that string: if you just concatenate the vector elements, then no, it's not equivalent. For instance, the following two vectors {"mast","err","apparent"} {"master","rap","parent"} both map to "masterrapparent".

Also, how does the hash function generate the key ? Boost.Hash combines the vector element's hash values as described at

http://boost.org/doc/html/id2490467.html B.MI also lets you specify your own hashing mechanism if you need it: http://boost.org/libs/multi_index/doc/advanced_topics.html#hash_spec Joaquín M López Muñoz Telefónica, Investigación y Desarrollo