Quote:
For instance:
Objects A B C D of type IMyObject
Container: std::map<unsigned int, IMyObject *>
key, value
0,A
1,B
2,C
3,D
4,E
5,A
6,B
7,C
8,D
9,E
I would argue here that 5,6,7,8 and 9 all point to different instances of A,B,C,D,E and therefore should have unique keys.
Right, I get what you're saying here. Though technically, they will be unique keys I think, just with the same values. The only way you would be able to tell duplicate keys apart is if you check the indexes. But is it even possible for a multimap to store duplicate key values? I see in the multimap reference, it mentions that it allows "different elements to have the same key value", but I think that means that it only allows different mapped values to have the same key value, and it doesn't mention if it also allows different keys with the same name to be mapped to the same mapped value.
Quote:
If you want to share the instances of A,B,C,D,E then you need some way of either sharing their keys or making them available. A reverse lookup map or multi-map would work or you could return the ID from the function that did the insertion and then make that available to those objects that need it. I'm not used to seeing identical values stored in a map under a different key - that is, when the values are pointers.
AFAIK, no one posted in this thread any identical mapped values that were pointers...
Quote:
I guess my reasoning is that if key 0 and key 5 have the same exact value you have now wasted memory by storing a shared object twice. Of course this only applies if you are storing pointers to objects in the map. But even if you map from int to int the key determines the uniqueness not the value.
1,1
2,3
4,1
5,2
6,2
So in this map from int to int if you want to get the value with a key of 1, it is 1.
I guess here you're referring to the map and not the multimap, since all keys are unique, only there are duplicate mapped values, each one mapped to a different key.
Quote:
If you want the value with a key of 4, it is 1. Why would you ever care about all the values that were 1? Yes they both have a value of 1 but that really doesn't mean anything in the context of this map. Obviously some other object thought it was necessary to store a 1 with a key of 4 or it would not have inserted it into the map.
If by "values" you mean "mapped values", then you might care about all the mapped values that are 1 if you were storing multiple instances of 1 in the mapped side of the map, for some reason. ;)