On Tue, Apr 14, 2015 at 1:37 PM, M.A. van den Berg wrote:

You can store your objects in a std::set instead of a map and then provide a custom compare function that compared your objects given your key in them. E.g.

struct my_compare { bool operator() (const MyObj& lhs, const MyObj& rhs) const{ return lhs.name < rhs.name; } };

std::set s;

set entries are const so this isn't usable in all cases. -- Olaf

On Wed, Apr 15, 2015 at 1:23 PM, David Hagood wrote:

One problem I see with using a set is that the whole data type is used as the key - if you do a find you have to supply the whole data type, not just the key, even though a custom compare operator may only consider part of the object as the key (to use the example use case I gave, you would have to supply a whole CF::Property to the find() function, not just the string).

See http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/reference/hash_ind... and its concept of Compatible Key. This does exactly what you want I believe. --DD

Thanks to everyone - yes, I think that is the solution I was looking for. I knew there had to be a solution - it just didn't make sense that something that solved problems like this didn't exist.

In my library Countertree ( set, multiset, map multimap concurrent and with access by position like the vectors ) I implemented the map as a data structure and a filter. Applying the filter you obtain the key. With the same nodes of the tree you can build a different maps, only changing the filter used. Imagine you have a map and each node have a code and a name, The map is sorted by the code. Extracting the nodes of the map, putting in a vector and inserting in map sorted by name,(the filter provide the name as key) it a easy operation. The access by positionof the trees , permit you new fast algorithms for create a map from a vector ( a 30000000 nodes need 6 seconds with 1 thread for to create a map, with 4 threads you can do in less than 3 seconds) The STL map need 35 seconds for to do it. All the implementations I know (GCC, VC++, Intel...) use a pair, and don't permit the change of the key The true problem is not to access to other element as use as second key, the problem is the sorting. If you need the data sorted by several keys simultaneously, you need multiindex. If when you sort by a second key, unsort the data by the first key, the procedure described could be good *The library countertree is pending of the final approval . You can find in https://github.com/fjtapia/countertree_2.0)