Let's say you have 26 strings (for convenience, a_map_s_v_s["a"] through a_map_s_v_s["z"]). You will have to create 26 vectors of strings to be mapped to, regardless of what approach you make. You've got approach 1:
Code:
vector<string> empty_vector;
not-really-for (key = "a"; key <= "z"; key[0]++) {
a_map_s_v_s.insert(pair(key, empty_vector));
}
//then for every key, value
a_map_s_v_s[key].push_back(value_string)
Now approach 1 has a sub-approach 1a that I wouldl have to poke through the standard to see if it works, which is simply
Code:
//then for every key, value
a_map_s_v_s[key].push_back(value_string)
trusting that if key hasn't been used before, a freshly-made sparkly-new vector<string> is handed to you at that time by the [] operator. If this works, and I suspect it will, then that makes this version look a lot more awesome.
Approach 2 isn't that different from approach 1, really:
[code]
Code:
not-really-for (key = "a"; key <= "z"; key[0]++) {
vector<string> empty_vector;
//for all the values that go with this key
empty_vector.push_back(value);
a_map_s_v_s.insert(pair(key, empty_vector));
}
You would have to know all the end-result strings in one place, though.