Thread: Free program I'm sharing: ConvertEnumToStrings

Originally Posted by Programmer_P

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)..

Hmmmm. So, I create an enum in a source or header file, parse it as text to return as a vector of strings representing the enum values?

Admittedly I didn't follow your explanation of the purpose of all this.

I can understand the following transformations:

text file -> c++

c++ -> text file

I can't wrap my brain around:

c++ -> text file -> c++

Is that what you're trying to do here?

Another potential use for this kind of thing is with long enums from libraries used, eg, as error codes. When you get an error code like that back, it can be a pain to have to figure out what the number means every time.

I deal with it this way:

Code:

#!/usr/bin/perl -w
use strict;

die "Input file required" if (!defined($ARGV[0]));

open(IN,"<".$ARGV[0]) || die "Couldn't open ".$ARGV[0]."$!";

print "switch (VAR) {\n";

while (<IN>) {
        (my $enum = $_) =~ s/[\s|\t]//g;
        $enum =~ s/,.*$//;
        print "\tcase ($enum):\n"
                ."\t\tstrcpy(STR_HERE,\"$enum\");\n"
                ."\t\tbreak;\n";
}

print "\tdefault:\n}\n";

close(IN);

to create a short function which returns the enum value as a c-string.

So your presumably your program will be good for that too.

Definetely better using enum than int, was just not thinking.
make_pair can be found here

But yes, map doesn't replace your program. Should you use map in your program? It would have saved you probably time.

I think people are mentioning map because it offers a way for the programmer to do quite easily what your program in the first place. Obviously, it is better to offer yourself a way to do this than use any other external program. So somebody could do

Code:

enum day{
    Monday,
    Tuesday,
    ...
};
...
map<string,int> dayStr;
dayStr.insert(par<string,int>(Monday, "Monday");
dayStr.insert(par<string,int>(Tuesday, "Tuesday");
...
day today = Monday;
cout << dayStr[Monday] << endl;
cout << dayStr[today] << endl;

So he would be able to easily get the string.

You could make a library with macros. But I cannot get my head of how to make this elegant for the users! But I am sure there is a way so the user can just type

Code:

DECL_ENUM(day)
  ENUM(Monday)
  ...
END_ENUM

and there will be an enum generated as well as an array of strings and finally a dayStr() function to get the appropriate string value.

Originally Posted by StainedBlue

Hmmmm. So, I create an enum in a source or header file, parse it as text to return as a vector of strings representing the enum values?

If you compile and run the program, passing to to it the --help argument, you will be informed how it works.

Admittedly I didn't follow your explanation of the purpose of all this.

I can understand the following transformations:

text file -> c++

c++ -> text file

I can't wrap my brain around:

c++ -> text file -> c++

Is that what you're trying to do here?

Not exactly...
Its more like:

enum in header or source file -> C++ string in program

C++ string in program -> header or source file

Essentially, what I do is I get the enum (various elements of it) of a source or header file passed to the program, then I write a class definition containing the enum values with a few functions to an output file (.h or cpp, .h by default). You can then use the functions generated by the program to get the enum value names and other elements of the enum.

You are attempting to treat enumerations as strings and although they appear to be strings in the code they are not. It would be nice if the language allowed us to convert an enumeration value to it's C++ string equivalent but it does not and probably for good reason. This entire thread, IMO, comes from a pure misunderstanding of what enumerations are and an improper use of them. C++ offers many more solutions to this problem without attempting to redefine what an enumeration is.

without hard-coding those string names yourself.

Eh? Who is hard-coding anything? Calling an enumeration hard-coded is a bit of a misnomer. If you use an enumeration and make it available to those using your interface how is that hard-coded? If you want a generic feature in your interface then you would not use an enumeration. There are many many more ways to do this. One could load an XML file that would then map certain values to strings. If you wanted to add a feature then you simply change the file and when your code loads it, it works. You could then also provide a way for someone to add a callback and when the new 'feature' is found in the xml file you would then just callback to the user who added the feature and they would then know how to deal with it. I just don't understand the point here at all.

Enumerations, by their very nature, are somewhat 'hard-coded' values but they are better than placing the raw value everywhere the enumerated value would be in the code. Bit wise comparisons and operations can also be performed on enumerations and are done quite often in a lot of code.

Take for instance the Direct3D enumeration for memory pools:

typedef enum D3DPOOL
{
D3DPOOL_DEFAULT = 0,
D3DPOOL_MANAGED = 1,
D3DPOOL_SYSTEMMEM = 2,
D3DPOOL_SCRATCH = 3,
D3DPOOL_FORCE_DWORD = 0x7fffffff,
} D3DPOOL, *LPD3DPOOL;

Are these hard-coded? From your point of view, certainly, but not from mine. These are the pools the library supports. It is far better for me to specify the pool I want as one of these enumerated types than it is to just pass in an integer. Can I check to see which pool a resource is allocated in via this enumeration? Certainly. If memory pools were something the designers thought would be ever-changing and ever-expanding then an enumeration would be a poor choice to store this information in since it would require you to recompile every time you change something.

For instance a game event system would NOT be a good place for an enumeration. Every time someone needed to add or remove an event the enumeration would have to change and everyone would have to recompile. This would be a nightmare with many people working on the project. So the solution isn't to create some weird enumeration util but it is to use a different data structure for the task at hand. There is an article about this exact thing in Game Code Complete 2nd. ed. where the author states that their event system used an enumeration early on but later was changed due to the exact problems I just described. Lesson learned = use the correct data structure for the job.

Programmer_P said...

If you compile and run the program, passing to to it the --help argument, you will be informed how it works.

Yes I did that. I even looked through the source. *How* to use your program is not what confuses me; *why* I should use it, does.

MK27 has pointed out one potential use, although there are many other ways to implement error checking and unit testing, and this route wouldn't be my first choice.

Originally Posted by Programmer_P

Actually, I wasn't attempting anything. I've already done it.
And so what if I'm treating enumerations as strings? This can be useful at times, and it certainly is useful in a web coder program I'm writing right now.

Maybe so, but so far I haven't seen any examples of all those wonderful "solutions" to the problem which I already talked about in a different thread which I started.
So it seems, you are wrong...

Ok, but this is the perspective others have....

"Hi, I have a program that helps you add two numbers together. It's called AddTwoNumbers. This is how it works...

Code:

int add(int a, int b)
{
    return a + b;
}

int main()
{
    int a = 1, b = 1;
    int c = add(a, b);
}

...Isn't that so much more convenient than using that confounded + operator? Enjoy!"

Originally Posted by Programmer_P

Those are actually two very different things.
What my program does is something that nothing else that I'm aware of can do (at least, automatically). You guys have posted many different "solutions" for converting enum values to strings, but so far, I have not seen any method which can replicate what I did (and that is, to provide a way of retrieving all enum values, or a specific enum value, without having to write all those enum value names again).

Arrrgh!

But this is exactly why in 99.9% of designs needing something like this would use a MAP.

Either an int mapped to a string, or vice versa, the MAP will accomplish this!



ARRRRGGGGH!