Re: [boost] Feedback desired for reflective enum library

Subject: Re: [boost] Feedback desired for reflective enum library
From: Geert Martin Ijewski (gm.ijewski_at_[hidden])
Date: 2019-01-12 07:48:37

Hi,

On 1/12/19 12:25 AM, Nir Friedman via Boost wrote:
> Hey,
> 
> I have a reflective enum library available here:
> https://github.com/quicknir/wise_enum. I've been working on this on and off
> for a couple of months. I've added features, dealt with various issues,
> added docs, expanded support through 11-17 and as idiomatically as
> possible. Overall I think the library is in nice shape (lacks unit tests
> though, though I do already have a boost license for the code).
> 
> I feel like a reflective enum is just a very standard requirement in pretty
> much every codebase I've ever worked on. Simply to be able to reasonably
> log enums already makes it mandatory. It's also invaluable in
> configuration, error message alerting, and many other places. There is
> nothing for this in boost and actually there isn't really much of a
> standard, standalone solution anyway. The closest is Better Enums (
> http://aantron.github.io/better-enums/), but this has some major issues (it
> doesn't actually create enums but rather enum-like classes, it targets 03).
> 

I only read the readme and didn't look at the code -- is there a way to
easily convert existing enums without changing the code to put it all in
a `WISE_ENUM()` block?

Maybe that is an unrealistic goal but theoretically a drop in
replacement that could do something like:
```
enum colors_raw {
   RED = 0xff0000,
   GREEN = 0x00ff00,
};
#ifdef WISE_ENUM
CONVERT_TO_WISE_ENUM(colors_raw, colors);
#else
typdef enum colors_raw colors;
#endif
...
void some_function(colors background);
```

and just having to change the name of the raw enum temporarily,
declaring the new wise enum type and then reaping all the benefits w/o
chaning my whole code base.

> So I think a library like this is needed and my implementation ticks off
> the major requirements. Feedback on the overall design, any issues, any key
> features it fails to meet, would be very useful. The library itself is very
> small and simple so its easy to review. Once it seems like there's some
> consensus on the core design I'm willing to do the work involved getting it
> into boost (naming conventions/requirements, directory structure, tests,
> boost-style docs, etc).
> 
> Note I'm not on the boost mailing list so please respond directly to this
> email so I can see!
> 
> Cheers,
> 
> Nir
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>