Re: [boost] boost] Attn metaprogrammers! [Better Enums] More complete release - feedback requested

On Jun 8, 2015, at 23:30, Gavin Lambert wrote:

The other interesting thing that you could do though was to have separate tables for separate contexts. So for example with the same actual enum, you could use one string table when reading/writing JSON and a different table when reading/writing XML -- or one string for internal use and another string for user display. That sort of thing. (Although there are better ways to handle the latter, especially once you start considering multiple languages.)

I think this is the only thing that’s not straightforward for me to support. I’ll give it some thought. There might be something that can be written over the core of Better Enums that does this nicely.

On Jun 9, 2015, at 09:08, Phil Endecott wrote:

In my case I was processing a file with key-value data; I needed to convert the key string to an enum. There were about 25 keys that I was interested in. Initially I had a sequence of if statements each doing a std::string::operator==(const char*). I changed that to a switch statement on the first character, followed by std::string:: operator==(const char*) for each of the keys with that initial letter. This increased the speed of that code 50X, and the speed of the overall file processing 2X. It was definitely worthwhile. There is an important special case - when the string is not one of the valid keys. If this is frequent in a particular application, a linear scan will do especially badly.

That’s a very good point.