Thread: Free program I'm sharing: ConvertEnumToStrings

Originally Posted by iMalc

Not so fast...

Yes logically a comma separates things and there is no need to separate the last thing from the nothing that follows.
However, this is intentionally accepted by the compiler and for good reason:
This is because it makes it easier to add an additional value later. Specifically since you don't have to alter the previous line to add the comma, a version control system doesn't indicate a change was made to the previous line. It also means reordering lines is easier as you don't have to worry about one line not having a comma.
It is very common and is indeed even considered good practice by many. It is done both with enums and array initialisation data.

For the record, stainedBlue was quoting what I said in the first post, and it seems having a comma after the last enum value in an enum doesn't work in all cases, because I've tried it before with the gcc compiler in Ubuntu, and it wouldn't compile. That is why I assumed that you're always not supposed to put a comma after the last enum value.

@Bubba: I can't tell if you're recommending that I change my program to use maps, or if you're recommending to use maps in place of my program. I'm willing to change my program to use maps, but I don't intend to use maps instead of my program.

And I don't care what you do with maps...it doesn't change the fact that you still end up having to manually type up the string names of the enum values if you don't use my program.

Originally Posted by C_ntua

Without looking exactly what your code does, you could use a map like

Code:

enum name{
    Mike = 0,
    John,
};
...
map<string,int> enumName;
map.insert(par<string,int>(0, "Mike");
map.insert(par<string,int>(1, "John");

then make a class that contains the enum and the map. You will make sure it is read-only if you want and static. You could use it like

Code:

Name x = Name::Mike;
cout << x.str() << endl;

where x.str() could return the string. To do so it would do something like

Code:

string& str()
{
    return this.innerMap[this.value];
}

and of course, you would overload the = operator so it assigns the value given to the "this.value". Where value would be an "enum name" and innerMap the map you use to map the string with the int value of the enum.

So you could create an "Advanced Enum" in order to have the additional functionality you want. The program will replace an enum with the advanced class.

Originally Posted by laserlight

Since you want to map enumerators to strings, C_ntua's example should actually be:

Code:

enum name {
    Mike = 0,
    John
};

// ...

map<name, string> enumName;
enumName.insert(make_pair(Mike, "Mike"));
enumName.insert(make_pair(John, "John"));

I was unable to find anything in the map reference called either "par" or "make_pair"...

Originally Posted by MK27

Sure, but you could write a similar program to do the same thing with maps. That you decided to do something a certain way is not a logical defence of the strategy -- that's circular.

Did I not just say I was willing to change my program to use maps...?

Originally Posted by Programmer_P

@Bubba: I can't tell if you're recommending that I change my program to use maps, or if you're recommending to use maps in place of my program. I'm willing to change my program to use maps, but I don't intend to use maps instead of my program.

Originally Posted by MK27

A pair is a separate (but related) datatype. Here's how you use it with map:

Code:

	map<string,int> test;
	test.insert(pair<string,int>("this",4));

Thanks.
Is the "pair" definition in the same header as map?

Pair and make_pair is in <utility>. Include that just to be sure.

Originally Posted by whiteflags

Pair and make_pair is in <utility>. Include that just to be sure.

Ok, thank you.

Originally Posted by MK27

What's done is done, obviously. I have code that works that I frequently use that I'd still love to re-write to work better and/or differently, but I don't have time. I'm sure that's true of most people.

I think the idea here was not necessarily to force you to scrap everything and start again, but more to point out the possibilities that you missed so you are aware of them in the future.

Yeah, but it wouldn't take me that long to change it to use maps instead if I wanted to, then re-upload it, and get Bubba to change the download link. Like already mentioned, I'm willing to do this if its such a big issue.
But my program works, as is, right now.

I do understand people's misconceptions about the program though. I forgot to mention in the first post that the program does more than just converts any enum. What my program does that makes it more valuable than that is it provides a function which returns a reference to a vector of enum value strings (automatically generated by my program). This makes it possible to get all the enum value names without typing them up. Thus, if you have a really long enum, for example, which has many enum values, and you don't want to type up each string name of those enum values, you can use my program to do it for you.