Saving hash_map keys in a vector

[Paul Bilokon]

Hi,

Is there a more elegant and/or efficient way of saving the keys from a hash_map in a vector? Perhaps using assign or other algorithms? The problem, of course, is that we are dealing with an iterator of pairs...

hash_map<string, void *> hashMap;
 
// ...
 
vector<string> keys;
keys.reserve(hashMap.size());
 
hash_map<string, void *>::iterator endIter = hashMap.end();
for (hash_map<string, void *>::iterator iter = hashMap.begin(); iter != endIter; ++iter)
{
    keys.push_back(iter->first);
}

Many thanks!

Paul

[RRick]

Why do you need to save them at all? You already have them stored in a hash table. One copy is enough.

If you do copy them to a vector, then you have to maintain two different lists of values. This is error prone and best avoided.

[Paul Bilokon]

RRick,

I'm concerned with two use cases.

First, I need to be able to produce a memento of the map. However, I don't care about the values for this purpose, I only need to remember the keys.

Second, I have a data structure whose underlying implementation (via composition) is a hash_map. I want to keep this data structure as simple as possible, so I don't want to make it (anywhere near) STL compliant and provide iterator access. So I enable the users of the data structure to query the keys that it contains.

Does this make sense to you?

Regards,
Paul

[RRick]

Okay, you have a hash map you don't want to make public. That is understandable but you also have some work arounds.

You can allow access to the hash_map as a reference to const hash map. Now, the caller can access the keys and data via const interators, and you don't have to do any extra coding. Please note, that lots of people have issue with this type of access, saying it breaks encapsulation. You'll have to make the decision.

The other choice is to provide the data in some other form. A vector of keys is reasonable, but has its limitations. You now have copy of the keys. What if things change? Who gets rid of the data? You can pass the vector to the app each time it asks or maintain it internally. Once again you get to make the decisions.

[Paul Bilokon]

Hi Rick,

Many thanks for your reply.

I do indeed feel uneasy about breaking encapsulation.

As far as the vector of keys is concerned, it's far from ideal, but I would make it part of the contract that this is only a snapshot, or a memento (although not in the strict Design Patterns sense of the word). Then I believe it should be OK.

This said, does the code that I pasted in my first message look reasonable to you (provided that we establish that vector<string> is the desired solution).

Once again, thank you for your help,

Paul

[RRick]

There's nothing wrong with the code. The issues are with the copies you are making.

For example, is the vector of keys created inside a method? If so, is the vector local to that method? If it is, you must pass back another copy of the vector.

Many times a simple idea has ramifications that go beyond the code needed to generate object. Sometimes, the maintenance of the object is more complicated that its creation.

[Paul Bilokon]

Thanks a lot for your advice, RRick.

I'm hoping that if I create the vector within a method and then return this vector, the additional copy will be removed by most modern compilers (return value optimisation).

Is this generally the case in your experience?

Many thanks,
Paul