Quote:
Originally Posted by
Bubba
It's just as easy to create a second map that maps values to a vector of iterators that point into the first map.
I have no idea what you mean by that. Could you post some example code for that?
Quote:
As long as you correctly maintain both maps during removes and inserts it works fine and it's less confusing and if you do it correctly there is hardly any additional overhead until you want to remove a value which might mean you need to remove one or more entries in the original map.
Ok...
Quote:
However, that being said if you need key off of values instead of keys or you need to do both and I would say there is a serious flaw in your design.
Interesting English. I think you meant:
Quote:
However, that being said, if you need to get a key value from a mapped value, instead of a mapped value from a key value, or you need to do both (?; I think we can remove that part completely...), I would say there is a serious flaw in your design.
In response to how I translated what you said, and not to what you actually technically said, I'd say that is a matter of opinion. I think there are times when you may have a map with some content, but what you really need is a map with the same content (of sorts), only the key values are the mapped values, and the mapped values are the key values. That's where my swap() function comes in handy.
Quote:
Multimaps were designed to map unique keys to one or more values and maps were designed to map unique keys to one unique value.
That is true, yet what we're talking about here, the container storing stuff doesn't start out as a multimap. It starts out as a map, hence each key will be mapped to just one value. It is only after using swap that it becomes a multimap. And now that I think of it, I don't think multimaps will be useful in this scenario at all. I'll go ahead and change it to a standard map.
Quote:
That is the intent of the data structure. Altering that design is not good and points to a flaw in your own design or to the idea that maps may not be what you need.
Technically, I wasn't altering any design at all. I was only taking the content of one map, and putting it another map, only with the key values as the mapped values, and the mapped values as the key values in the new map.
That is not changing the underlying design of a map at all. It is only changing what is what in what, or something to that effect.
Quote:
Most of these types of problems can easily be solved by re-design and/or by making use of multiple STL containers.
Maybe. But I'd need to see some of these "easy" solutions to this problem in action first before I decide whether that is really the best idea or not.
Quote:
If you understand the STL you can build the system so it adds minimal overhead at the cost of a bit of memory. However the memory that would be saved in another approach does not justify the convoluted code and logic it requires to accomplish. When you run into situations like this it is often best to use the approach that makes the code the clearest.
I'd say the code is pretty clear...
Code:
CnameofenumToStrings classObject;
map <string, unsigned int> enumerationsMap = classObject.getEnumerationsMap();
multimap <unsigned int, string> swappedMap = swap(enumerationsMap);