Initializing static arrays with enum indices

[theBNich]

Hi, I currently have an enumeration in class Lexer:

enum lexType {
 
    /* token keywords */
    lexIF, lexTHEN, lexWHILE, lexDO, lexBEGIN, lexEND, lexELSE, lexPROGRAM,
 
    ...
 
    /* used for array iterations */
    lexENUMSIZE
};

I have an array used to get the string representations of these types:

const char* lexTypeNames[lexENUMSIZE];

This array is currently populated in the class's constructor:

Lexer::Lexer() {
    lexTypeNames[lexIF]             =   "lexif";
    lexTypeNames[lexTHEN]           =   "lexthen";
    lexTypeNames[lexWHILE]          =   "lexwhile";
    lexTypeNames[lexDO]             =   "lexdo";
    lexTypeNames[lexBEGIN]          =   "lexbegin";
    lexTypeNames[lexEND]            =   "lexend";
    lexTypeNames[lexELSE]           =   "lexelse";
    ...
}

Finally, I have a method in the class to retrieve the string representation given a lexType:

const char* Lexer::getLexTypeName(lexType type) const {
    return lexTypeNames[type];
}

The problem with this set up is that if another class has a lexType and I simply want to get the string representation of this lexType, I have to create a new instance of the Lexer class before I can call getLexTypeName(). Therefore, I was hoping there was some way to make getLexTypeName() static so I could simply call Lexer::getLexTypeName(lexType). I know I could do something like this:

static const char* lexTypeNames[] = {"lexif", "lexthen", "lexwhile", "lexdo", ...};

However, this seems like a very error-prone solution that depends on the order of the enumerated elements for a correct initialization. Is there some way to statically initialize the array by manually specifying the indices like I did in the constructor? If not, is there a more elegant solution for this?

Thank you,
Brian

[weaknessforcats]

You should not have to a) use static arrays or b) access array elements directly and c) use arrays at all.

I suggest you convert your array to a vector. vectors are required to be implemented as arrays so you still have your array. But you also have the vector code to manage the array instead of writing it all over again.

Put the vector inside a class and make all access to that vector go through a class member function. That will hide the vector.

Next, make this a Singleton class. Singleton classes are classes that can have only one instance. If you do that then there is one instance of your array that all classes can use.

Read the Insight article on the Singleton class. Complete information is there on how to set this up.

[theBNich]

Thanks for the Singleton suggestion--I've implemented it, and it's a nice solution. However, I'm not sure I understand why to use vectors instead of arrays here.

I suggest you convert your array to a vector. vectors are required to be implemented as arrays so you still have your array. But you also have the vector code to manage the array instead of writing it all over again.

In general, I do use vectors over arrays for the reasons you stated. In this case, however, I'm simply creating an array, mapping strings to each index, and then accessing each index without any further modifications to the array thereafter. How do vectors help rather than arrays in this case?

Thanks.

[weaknessforcats]

A vector is required to be implemented as an array.

The vector member functions manage that array. No more screw-ups and memory corruptions.

OR:

You can create your own arrays.

Write code that duplicates vector<> member functions. Time sink.

Write code differently each time. Maximize your maintenance costs.

Write code that's slower than vector<>. Almost always the case. STL templates are all optimized ofr speed.


My rule is: Unless you can write down on paper why a vector<> won't work, then use the vector<>.

It gets worse. STL does not want you to write any more linked lists, trees, loops, etc since there are replacing templates for all these things (and a whole lot more). The hard part is that since you spent 5000 years learning how to do all this stuff, to ditch that in favor of some whiz-bang templates is tough.

It goes easier to just give up at the outset.