Thread: Free program I'm sharing: ConvertEnumToStrings

Can you give me the code so I can learn something different

You can add something like the following to something like `BOOST::PP_FOR_EACH'. (I don't remember what it is called.) With the above primitive you'd have something like:

Code:

STDX__ENUMERATOR__ENUMERATE(my_enum, (string1, 1) (string2, 2) (string5, 5))

for the interface. I'm just to lazy to write those primitives for such a trivial example.

I provided a means of getting a reference to a vector of all enum value names, without typing up all the enum values again.

Exactly. Hence the statement: "generate a string/value association from a string/value association".

no one has yet posted an example of a truly better method of what my program does

That could be because your program doesn't do anything. Or rather, there are a bazillion ways to do it. It isn't difficult. It is extremely trivial. This is elementary parsing and generation. It is a good stepping stone. You probably learned some good things writing it, but it isn't something to trump the very simple ideas that have been posted several times.

Have a look at this for my simple version, it ain't brilliant so it'll barf if you use value assignment in the enum list.

That's not bad at all.

Soma

Code:

#define STDX__APPLY(FUNCTION) FUNCTION

#define STDX__ENUMERATOR__DEFINITION_INITIALIZER(NAME) \
	enum	NAME \
	{

#define STDX__ENUMERATOR__DEFINITION_CALLBACK(VARIABLE, VALUE) \
		VARIABLE = VALUE,

#define STDX__ENUMERATOR__DEFINITION_FINALIZER(NAME) \
		NAME##__UUIDB49527AC_8FBC_4DCD_93C7_56D122ADF592 \
	};

#define STDX__ENUMERATOR__MAP_INITIALIZER(NAME) \
	const char * NAME##__GET_STRING_FROM_VALUE (NAME value) \
	{ \
		switch(value) \
		{

#define STDX__ENUMERATOR__MAP_CALLBACK(VARIABLE, VALUE) \
			case VALUE: \
			{ \
				return(#VARIABLE); \
			}

#define STDX__ENUMERATOR__MAP_FINALIZER(NAME) \
		} \
		return("(null)"); \
	}


#define STDX__ENUMERATOR__APPLY(NAME) \
	(STDX__APPLY(STDX__ENUMERATOR__##NAME##_INITIALIZER), STDX__APPLY(STDX__ENUMERATOR__##NAME##_CALLBACK), STDX__APPLY(STDX__ENUMERATOR__##NAME##_FINALIZER))

#define STDX__ENUMERATOR__ENUMERATE(NAME) \
	STDX__APPLY(STDX__APPLY(NAME##__VALUE_DEFINITIONS) STDX__ENUMERATOR__APPLY(DEFINITION)) \
	STDX__APPLY(STDX__APPLY(NAME##__VALUE_DEFINITIONS) STDX__ENUMERATOR__APPLY(MAP))

#include <iostream>

#define my_enum__VALUE_DEFINITIONS(INITIALIZER, CALLBACK, FINALIZER) \
	INITIALIZER(my_enum) \
		CALLBACK(string1, 1) \
		CALLBACK(string2, 2) \
		CALLBACK(string5, 5) \
	FINALIZER(my_enum)

STDX__ENUMERATOR__ENUMERATE(my_enum)

int main()
{
	int test;
	std::cin >> test;
	// too lazy to write the stream operator
	std::cout << my_enum__GET_STRING_FROM_VALUE(static_cast<my_enum>(test)) << '\n';
	return(0);
}

1. If you are going to search for a library or a ready-solution BEFORE you start writing you code to have the "enum with added feature" that you want, you would go with the macro solution. That is what you really want.
2. If you don't want a library you would just spent a few minutes writing the strings into an array. Better (though a bit slower) use a std::map.
3. If you ALREADY had a program with enumerations and you wanted to change it, you would go with Programmer_P's external program approach. Why re-write your enums with macro-version and not use the above approach?

So depends on what you want. Note that downloading libraries that are not guaranteed by someone trustworthy is not a good idea when it will involve macros or programs/scripts that will change you code. If there was a standard way to do so, the above is negated.

Note that 3 will require you to run the external program every-time. So you would have to make a script file for every project you make in order to run and test quickly. Adding more to the to-do-list.
Method 1 can be a bit tricky. If you want to use typedef for your enum, for example, you might end up with nonsense. If you use it inside a class it might simply not work, because you will get a compile error for initializing the string-array/map in the wrong place. So it is not that universal. The same problem you might have with approach 3.
So going back to my previous paragraph, you have to clearly state where exactly you can use such a method. Adding more to the to-read list.
Again, if there was a standard way, you would avoid all of these things.

So most of the time you will go with approach 2 or in other words, if you have a seriour project this will be a really minor task.

Don't get me wrong, there is usefulness in this program, but there is no reason to compare them since the 3 situations are completely different.

Does that conclude this?

But as yet, no one has yet posted an example of a truly better method of what my program does. And I mean the automation part.

Actually, we have. I posted source for how to use a map to do an int/string mapping but you are too caught up in your own way of thinking to see how you can leverage it for your uses. Now we are getting into territory where you don't care what everyone is saying and instead are pushing your program. Everyone here is telling you the same thing. Listen to it.

We have shown you several examples of how to do it. And if you think all this macro hideousness is any better I have news for you it is not. Now as we can see every 'workaround' or attempt to make enumerations into something they are not has ended with a mess. I map strings to ints and ints to string or A to B and B to A pretty much everyday of my life and I would never, repeat never, do it the way you have here. Mapping a key to a value is definitely nothing new and there are several good ways and several very bad ways to do it. And I believe all of this thread comes from a fundamental incorrect use of enumerations. Enumerations are not, never will be, and should not be viewed or used as strings in any sense of the word. This is why the language does not allow us to do this but it does provide a billion other ways to gain the functionality you would need.

So in your case it is plain and simple. An enumeration is a poor choice for this task. No amount of code sitting on top of that poor choice makes the choice better just b/c the end solution works. It is still a poor choice. The problem with your code is it attempts to turn a standardized piece of the language into something it is not. I also have some advice for you. If you ever write code professionally and half the studio disagrees with your code and have very valid reasons for doing so and all you find yourself doing is defending it - there is probably something wrong with your code or your design. Everyone cannot be wrong.

I want to change situation 3. It was a stupid one actually. There is no chance that you will have a program where you want to change enumerations to provide them to give you the string.
So, you are left with one choice (situation 1). To either use an external program or macros. Macros are better. But might not be complete if you cannot use them inside a class, which is usually the case where you want enum-to-string functionality.
Using a std::map is the standard method and its preferred for various reasons even if it needs more work than the macro version.

You can have a class

Code:

class card
{
    enum Suit
    {
          Diamonds, Hearts, Clubs, Spades
     }
     Suit suit;
     void id() {cout << "This card is.... of suit " << suitStr(suit) << endl; }
}

You have want to tell the user what kind of suit the card is. You already define it, so you want a simple way to do this.
Why have an enum and don't do something like

Code:

#define Diamonds "Diamonds"
//so there is a compile error if you write suit = "diamonds" instead of suit = "Diamonds"

The only reason is speed since you can compare enumarations (int) faster than strings.
There is no better way to do this than the standard way (declaring the strings). It would have been nice if there was a standard/nice way to do so, like a compiler extension.

Originally Posted by C_ntua

1. If you are going to search for a library or a ready-solution BEFORE you start writing you code to have the "enum with added feature" that you want, you would go with the macro solution. That is what you really want.
2. If you don't want a library you would just spent a few minutes writing the strings into an array. Better (though a bit slower) use a std::map.
3. If you ALREADY had a program with enumerations and you wanted to change it, you would go with Programmer_P's external program approach. Why re-write your enums with macro-version and not use the above approach?

It seems you misunderstand what my program does, and you put slanted bias on my method just because everyone here seems to want to diss everything I say and/or do.

So depends on what you want. Note that downloading libraries that are not guaranteed by someone trustworthy is not a good idea when it will involve macros or programs/scripts that will change you code. If there was a standard way to do so, the above is negated.

Note that 3 will require you to run the external program every-time. So you would have to make a script file for every project you make in order to run and test quickly. Adding more to the to-do-list.

Every time would actually be not very often. And so I see no reason why you would need a script to use my method at all. Just run the program once for every source file or header you need an enum (or enums) translated to strings, and be done with it.

Method 1 can be a bit tricky. If you want to use typedef for your enum, for example, you might end up with nonsense. If you use it inside a class it might simply not work, because you will get a compile error for initializing the string-array/map in the wrong place. So it is not that universal. The same problem you might have with approach 3.
So going back to my previous paragraph, you have to clearly state where exactly you can use such a method. Adding more to the to-read list.
Again, if there was a standard way, you would avoid all of these things.

In regards to the bolded part...you wouldn't, since every enum value string is already initialized.

So most of the time you will go with approach 2 or in other words, if you have a seriour project this will be a really minor task.

You mean you will go with approach 2.

Don't get me wrong, there is usefulness in this program, but there is no reason to compare them since the 3 situations are completely different.

Does that conclude this?

Not particularly...

Originally Posted by Bubba

Actually, we have. I posted source for how to use a map to do an int/string mapping but you are too caught up in your own way of thinking to see how you can leverage it for your uses. Now we are getting into territory where you don't care what everyone is saying and instead are pushing your program. Everyone here is telling you the same thing. Listen to it.

In regards to the bolded part, I looked at that code, and I saw that you still have to pass the string names of the enum values to get back those same string names. That defeats the whole purpose...
In regards to the rest of it, its simply not true. I care what everyone is saying, and I have read it, and understood, I just did not see that any of the methods posted are better than mine. And just because everyone is telling me the same thing, doesn't mean everyone is right. 100 wrongs, for example, doesn't make a right. It just makes 100 wrongs. But yes, I suppose its all a matter of opinion. Everyone will always use what they're familiar with the most, usually, and seek to diss everything else that doesn't fit inside that box. Anyway, forgive me if I'm only defending my method, which everyone seems to be doing their very best to attack with great vigor.
Anyhoo, I enjoy arguments and debates, really I do. Don't get the wrong idea, and think I'm mad at anybody, because that is not the case.
In fact, a lot of the posts in this thread made me grin, and I enjoyed replying to them.

We have shown you several examples of how to do it. And if you think all this macro hideousness is any better I have news for you it is not. Now as we can see every 'workaround' or attempt to make enumerations into something they are not has ended with a mess. I map strings to ints and ints to string or A to B and B to A pretty much everyday of my life and I would never, repeat never, do it the way you have here. Mapping a key to a value is definitely nothing new and there are several good ways and several very bad ways to do it. And I believe all of this thread comes from a fundamental incorrect use of enumerations. Enumerations are not, never will be, and should not be viewed or used as strings in any sense of the word. This is why the language does not allow us to do this but it does provide a billion other ways to gain the functionality you would need.

Interesting. And yet, all those "billion other ways to gain the functionality I would need" have still yet to be demonstrated.

So in your case it is plain and simple. An enumeration is a poor choice for this task. No amount of code sitting on top of that poor choice makes the choice better just b/c the end solution works. It is still a poor choice. The problem with your code is it attempts to turn a standardized piece of the language into something it is not. I also have some advice for you. If you ever write code professionally and half the studio disagrees with your code and have very valid reasons for doing so and all you find yourself doing is defending it - there is probably something wrong with your code or your design. Everyone cannot be wrong.

Actually, they can be. Just because the popular vote is saying something common, that doesn't always mean that what they're saying is 100% true (and I mean true in the sense that its easier to use than other methods). Perhaps "everyone" is just unwilling to think outside of the box of what has already been done.

Originally Posted by C_ntua

I want to change situation 3. It was a stupid one actually. There is no chance that you will have a program where you want to change enumerations to provide them to give you the string.

For the record, nobody's changing enumerations. My program merely retrieves the string names of the enum values without changing the enum at all.
And I found I had a need for such a thing. That is why I wrote the program to begin with.

Originally Posted by Bubba

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?

Ok, it seems I missed your edit before.
For the record, I wasn't calling the enum itself "hard-coded".
I meant, the string names of the enum values have to be hard-coded when you want to get those names, unless you use my program or something similiar.

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.

Let me help clear up some of those cobwebs in there...
Ok...I am using an enum, and need the enum value names because...its easier than using any kind of file. I want to make my program as portable as possible, and it doesn't seem to me to be the best idea to use an XML file or any other kind of file to provide a means of retrieving certain strings. I am using an enum because its easy to have an enum object/variable in the parameter of the getListOfSupportedAttrs() function as the method of specifying which list to return for a particular element.
The reason I need to convert enum values to strings is, it makes sense to return a list of the supported attrs using their corresponding enum values, rather than the strings themselves. For one, the string attrs are private, while the enum (and all its values) are public. For two, the content of all string attrs are a lot longer strings than their corresponding enum values, and I dislike having to concern myself with the content of the attrs' strings while trying to return a list of the supported attrs for a particular element. Using my program, and its provided methods, I can just call the getEnumValues() function to get access to a vector of strings containing each enum value of the ET_ELEMENT enum, and iterate through the vector, checking for a particular enum value name.

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:


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.

Ok, what would be your recommendation for a data structure to use then if not an enum?

Originally Posted by phantomotap

It involves the use of templates to solve a multiple inclusion problem, but it can be fixed.



O_o

Fail.

The standard doesn't say that a `switch' block must explicitly handle every case.

The only way GCC would have given you that error is with the `-Wall' or the specific option whichever it may be.

Actually, it wasn't GCC, I don't think. I tested it at codepad.org. I'm not sure what compiler they use there.

Bull......... You aren't that important. You are a newbie and sometimes a newbie needs a thump on the head.



This is obviously not true. The problem is that you are suffering from defending your program. I've read this thread and your other related threads completely. You do not need an enumeration to solve this problem. You need a `std::map'.

That be as it may. I'll shut up, and start exploring other options, including the std::map. I definitely want to get better at those, so I can see if they're really better than enums or not for my code.

They have been demonstrated numerous times. You are to busy defending your program to realize that you have been offered multiple better ways.

Correction: what I was offered was other ways to convert enum values to strings (none of which seemed to me to be better than my method, though I can admit I can be wrong sometimes), not other ways to specify an html element or attribute in a function.

You have done nothing new. You are not thinking outside the box. You wrote a program to translate a string/value table into another string/value table. Congratulations. You had a problem. You solved the problem. WE ARE TELLING YOU HOW TO SOLVE IT THE RIGHT WAY!

Soma

*snoring...*

I think we criticized enough. The points have been said.

For the actual program, how can you compile this without an IDE? Tried, but doesn't work, just gives me the information.

Based on the information ONLY
1) Shouldn't it be better to support all possible formats? What if it is on a single line? If you have

Code:

enum A
{
 a,
 b
};

will it work?
2) What if the enum is not on an header file? Will you program still work? If you have multiple enumerations on a single header file?
3) I see nothing about support for class when you tell me on your post that it does support them!!! Before testing a program, I will read the instructions. If I feel it might not work, I won't use it. Wouldn't you do the same? Here is an example

Code:

class Day {
	enum day {
		Monday,
		Tuesday
	};
}

Now I am thinking that your program might do something like

Code:

class Day {
	enum day {
		Monday,
		Tuesday
	};
	char* values[] = {"Monday", "Tuesday" }
}

Which is invalid. Maybe your program does something different, but you have to specify this on the instructions.

All this questions come in mind. THAT is why I said that a non-standard way has its problems.
A macro version can still have this problem***

Not trying to discredit this work. You just have to remember that your program can be extremely useful for yourself, but others don't know their implementation, so you would have to provide them with all the necessary information first in order for them to use them.

You would need a simple script in order to run your program AND the program you want to run. And every time is a lot of times when you are testing! Lets say you change your enum. Don't you have to run your program again? You won't want to forget and mess things up.


**phantomotap might have in mind a version that supports classes, but that is not the case for ALL macro versions. Of course, you could try and add support for classes. But how are you going to initialize the strings?? You cannot initialize them in the class. You can create an initializer function for them, but then you have to call it somewhere. But then again, I am not a macro expert...