Originally Posted by
MK27
As I said clearly quite a few times, I was describing an alternative to that, and then you kept asking me questions about it, so I continued to describe it. Obviously you would not use both methods.
I don't recall you saying "quite clearly" that it was an alternative any time, but maybe that's just me...
But yeah, I understand that its an alternative. I was just questioning if it was in fact better than my method.
Sorry, I mean effectively "const", as in, are not changed after they are created. This is essential to the value of your method.
Yeah, true. Like I already said, you should never try to modify either one of the maps (the original or the swapped). And anyone with any sense wouldn't, either. Why do it? There is no point.
You already have a map for the enum. If you need a map for something else, create a different map. Its that simple.
So if the programmer using this interface wants to use several such maps in a program at once, you are leaving the burden on them to create a "swappedMap" for each map, and somehow keep track of this
relationship.
Only for those maps they want to swap (which I doubt would be that often anyway). But yeah, that's the idea...
And anyway, I already provide other methods for getting the string names of the enumerations:
Code:
const vector<string>& getEnumerationNames();
and
Code:
const string& getEnumerationName(nameofenum enumeration);
You can get any enumeration's name you want with the second method. And the first method returns a vector of the string names of ALL enumerations, so you can also do something with that as well.
Let's say I have 3 different mapped enums. I create a swapped map for each of them:
Code:
multimap <unsigned int, string> swappedMap1 = swap(enumerationsMap1);
multimap <unsigned int, string> swappedMap2 = swap(enumerationsMap2);
multimap <unsigned int, string> swappedMap3 = swap(enumerationsMap3);
Do you not see how it would be better to be able to refer to this:
Code:
enumerationsMap1.swappedMap;
Actually, it would probably be something like:
Code:
enumerationsMap1.getSwappedMap();
if I were going to do it that way. But yeah, the syntax might be a little better using the method you demonstrated. But both methods would work.
And unless I see significant justification for a swapped version of the original enumerationsMap as a member of each enum's class, there's no reason to add that functionality in.
This means the programmer does not have to number the variables in parallel (a very weak an inflexible method) or come up with there own derived class or a typedef like this:
Code:
typedef struct {
map <string, unsigned int> enumerationsMap;
multimap <unsigned int, string> swappedMap;
} emaps;
Which is what I would do if the class interface did not provide another means.
Ok, yes, I see what you're saying. You seem to think that adding both maps (original and swapped) to a struct has some advantage over just keeping them both as a their map types, and doing stuff with them directly. I don't really see the point to such an approach.
Either way, you still end up having to access a member of the map to do something useful with the map (i.e. retrieving a string name of an enumeration referred to by an unsigned int). And if I were coding and doing something like that with multiple enums, I'd think I would just write the code in a logical order, i.e.
Code:
//map the first enum
//if you need to, swap the map
//use the swapped map for something
//map the second enum
//if you need to, swap the map
//use the swapped map for something
as opposed to:
Code:
//map the first enum
//if you need to, swap the map
//add both maps to a struct
//create an object of the struct
//use the structObject.originalMap for something
//use the structObject.swappedMap for something
or
Code:
//get the map of the first enum
//get the swapped map of the first enum
//if you need to, use the swapped map for something
Yes, as I said I do understand what you are doing: for the second time, a function does not need to be part of a class for the class to use that function.
Exactly. I thought you were saying that the swap() function itself was a member function.