Annamalai Gurusami escribió:

Thank you very much for the response. Now I understand that identity<> is not an MPL construct. I was reading through the identity.hpp file and I think I understand it now. It can be used to convert chained pointers and smart pointers to references. For example,

int ****i; identity<int> get_ref; get_ref(i); // This will return me a reference to the integer

Let me know if I got that right.

Correct. You hopefully don't need to read the code directly to learn that, as is explained at http://www.boost.org/libs/multi_index/doc/tutorial/key_extraction.html http://www.boost.org/libs/multi_index/doc/reference/key_extraction.html

But since the template arguments are type names is there any reason why we need to use identity in template arguments? For example, in the code snippet given in the documentation, (my question embedded in the code fragment below as comments),

typedef multi_index_container< employee, indexed_by< ordered_unique<identity<employee> >, // Why is identity required here? // Why is ordered_unique<employee> not sufficient? ordered_non_unique<member<employee,std::string,&employee::name> >, ordered_unique<member<employee,int,&employee::ssnumber> >

...

...

employee_set;

Since the std::set doesn't require anything other than the type name of the elements it would hold, why does boost::multi_index::ordered_unique need this identity<>? What are the additional benefits of this added complexity?

STL associative containers like std::set and std::map use the notion of a key associated to a value, although they do so in an implicit manner: set<T> --> value_type=T, key_type=T map<K,T> --> value_type=std::pair<const K,T>, key_type=K In both cases keys are extracted from value_types through a fixed process: set<T> --> key(element) = element; map<K,T> --> key(element) = element.first; // element is a std::pair So you could say that std::set and std::map implicitly use key extractors, at least in an incipient form. For instance, the key_extractor of std::set<T> is functionally equivalent to identity<T>. Boost.MultiIndex simply makes this key extractor notion explicit by having the user specify which key extractors are used for each index. Why making this explicit instead of relying on implicit key extraction mechanisms like the STL containers? The simple reason is that STL containers are singly indexed and can afford assuming a fixed key extraction process, but multi_index_containers are precisely multi-indexed, so it's almost guaranteedly the case that you'd need different keys for each index, all of them extracted from the same value_type. Hence all the key extraction framework. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo