Thread: Enumerators as strings

Is there a better way to extract enumerators names, other than using a vector<string> to match the enumeration?

Code:

enum ESomeEnum { Opened, Closed, Locked };

vector<std::string> SomeEnumStrings(3);
SomeEnumStrings[0] = "Opened");
SomeEnumStrings[1] = "Closed");
SomeEnumStrings[2] = "Locked");

int main() {
    CDoor myDoor;
    myDoor.setStatus(Closed);

    std::cout << "The door is " << SomeEnumStrings[myDoor.getStatus()] << "." << std::endl;
}

>I think map would be better than vector.
A map is better when the index is a string, but in this case it seems that the index is an integer. The only real issue is that the enum and vector have to keep the same order, which could be an annoying maintenance problem that a map handles automatically. Then again, the contiguous memory of a vector could be a deciding factor, as could the fact that a map is a more complicated data structure and there could be performance or footprint issues.

That said, I would probably use a map.

You could do it the Mozilla way:

some_include.h:

Code:

LOCAL_ENUM_VALUE_MACRO(Opened)
LOCAL_ENUM_VALUE_MACRO(Closed)
LOCAL_ENUM_VALUE_MACRO(Locked)

user.cpp:

Code:

#define LOCAL_ENUM_VALUE_MACRO(v) v,
enum ESomeEnum {
#include "some_include.h"
ESEDU_COUNT
};
#undef LOCAL_ENUM_VALUE_MACRO

#define LOCAL_ENUM_VALUE_MACRO(v) #v,
const char *const ESomeEnumStrings[] = {
#include "some_include.h"
}
#undef LOCAL_ENUM_VALUE_MACRO

Not necessarily pretty, but it works, and it keeps the two in sync.

A map it will be. Thanks everyone

On a not so related note... why am I not being able to create a vector at the global scope?

Code:

#include <vector>

std::vector<int> myVector(3);
myVector[0] = 1; // error
myVector[1] = 1; // error
myVector[2] = 1; // error

int main() {
 /* ... */
}

I get the following error at every assignment attempt:

expected constructor, destructor, or type conversion before '=' token

What could be considered good norm to do this?

Declare the global on my utils header file and define a init() function where these globals are defined?

Code:

// utils.h
#include <vector>
extern std::vector<int> myGlobal;

//utils.cpp
#include "utils.h"

void init() {
    std::vector<int> myGlobal(3)
    myGlobal[0] = 1;
    /* ... */
}
/* ... */

//main.cpp
#include "utils.h"

int main() {
     init();
    /* ... */
}

The vector (in fact it will be a few maps) will hold strings. Much like what is provided with a resource file. Some maps will map to enumerators, but the 3 biggest ones will provide the support for a series of random generated item names (ala Diablo II item generation); "brilliant longsword of maiming", "crude helm of Yark", ....

Ok... sorry to bother you Daved. I'm having a blond day...

But you mean putting each map inside his own class?
I wouldn't need more than one instance of this class. Or is that you mean the map would be a static member of the class and there wouldn't be any need to create instances to use it?

I think that you should create your global vector, do the initializing in a function, and then work with that vector throughout the program. You just need a list of stuff right now. Right?

Code:

vector<string> PCEquipment;

void setup_equipment() {
   if (PCEquipment.empty()) {
      PCEquipment.push_back( string("brilliant longsword of maiming") );
      PCEquipment.push_back( string("crude helmet of Yark") );
      PCEquipment.push_back( string("stein of mead") );
   }
}

what have you and then actually use the list throughout your game. Of course, you may find out later it's easier to refactor this list into it's own class. Except now that you have done some preliminary work with the list, you can refactor it into a user-defined type that does exactly what you need and you have made zero design presumptions too early.

However because it's just a global vector I wouldnt give it it's own header. Keep everything in the source file for now, you can make header files later for this if you refactor it.

I think that's what Dave wants to say, but even if he didn't, I wanted to make sure that I wrote this down.

Ok gentleman. I believe I understood what's involved now.

Thanks