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

Subject: Re: [boost] boost] Attn metaprogrammers! [Better Enums] More complete release - feedback requested
From: Anton Bachin (antonbachin_at_[hidden])
Date: 2015-06-09 14:42:32

> On Jun 8, 2015, at 23:30, Gavin Lambert <gavinl_at_[hidden]> 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 <spam_from_boost_dev_at_[hidden]> 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.