We currently have a unordered_map< Uid, shared_ptr<Identity> >, where Identity already contains the Uid. So I thought I could avoid the duplicated Uid by using an unordered_set< shared_ptr<Identity>, MyHash, MyPred > to hash/compare by the internal Uid, but unlike a Multi-Index hashed_index [1], unordered doesn't seem to provide: "lookup operations accepting search keys different from the key_type of the index, which is a specially useful facility when key_type object are expensive to create." Any reason why unordered cannot allow similar "compatible key" lookups? What kind of overhead is there (memory use, runtime), if any, in using Multi-Index as opposed to unordered_set in this scenario? Using Multi-Index yields a more complex type and slower compiles it seems due to its meta-programming uses I guess. Thanks for any insight. --DD [1] http://www.boost.org/doc/libs/1_40_0/libs/multi_index/doc/tutorial/basics.ht...