Re: [boost] Is there interest in a library for string-convertible enums?

Subject: Re: [boost] Is there interest in a library for string-convertible enums?
From: Jeffrey Bush (jeff_at_[hidden])
Date: 2014-11-17 04:16:39

>
> Jeffrey Bush wrote:
>
> > I have also offered a class for doing this as well, although it didn't
> draw
> > the interest that this one did.
> > Here was my attempt at it with a test/example class:
> > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81
>
>
>
>
> Looks good to me, and seems to be quite close to what I aim at.
>
> But the definition seems very user unfriendly. Is it correct that
>
> you always have to declare enums in the public namespace?
>

> ---
>
> Felix
>

Sorry for the delayed response.

It does support being in a public namespace, even as a sub-class. However
the definition does get uglier in sub-classes.

The major problem I ran into was that the class could not be defined in a
header file without getting multiple-definition or as a sub-class without
running into problems. Mainly because of the constant arrays in the classes
couldn't be defined in-line and in headers. Some C++11 features may help
get around this.

I do think that when these issues are ignored the declarations are pretty
nice:

BOOST_FLAGS_WITH_VALUES(MyFlags, std::uint8_t, A, 1, B, 2, AB, 3, C, 4);

BOOST_FLAGS(MyDefaultFlags, AX, BX, CX, DX, EX, FX, GX, HX);

namespace MyNS

{

        BOOST_FLAGS(MyFlags, M, N, O, P, Q);

}

That makes 3 different enumerations, first with custom values and a custom
base (uint8_t), the second with default values (powers of two) and selects
the smallest base type, and the third is the same but in a
non-public-namespace. All of these don't work in header files without
getting multiple definitions. To avoid that problem you can do something
like:

// In H file:
BOOST_FLAGS_DECL(MyFlags, M, N, O, P, Q);

// In CPP file:

BOOST_FLAGS_DEFN(MyFlags, M, N, O, P, Q);

The same technique can be used to make sub-classes (as in the example
file). If I remember correctly if the ability to go from string -> value
and get list of values at runtime then the ugliness of the separate
DECL/DEFN would be avoided.

Jeff