[GSoC] Header Generation for C/C++

[Gregor Mückl]

On Monday, 22 July 2019 at 18:12:01 UTC, Manu wrote:
> Great idea!
> We can make the generated header emit this:
>
> #ifndef D_ENUM
> # define D_ENUM(name, type) enum name
> #endif
> #ifndef D_ENUM_KEY
> # define D_ENUM_KEY(key, enumType) enumType##_##key
> #endif
> #ifndef D_ENUM_KEY_VAL
> # define D_ENUM_KEY_VAL(key, value, enumType) enumType##_##key 
> = value
> #endif
>
> D_ENUM(DEnum, int)
> {
>   D_ENUM_KEY(A, DEnum),
>   D_ENUM_KEY_VAL(B, 10, DEnum),
> };
>
>
>
> And then someone can override those with:
>
> #define D_ENUM(name, type) enum class name : type
> #define D_ENUM_KEY(name, enumType) name
> #define D_ENUM_KEY_VAL(name, value, enumType) name = value
>
> #include "my_d_header.h"
>
>
>
> And for over-powered win, define the macros like this:
>
> # define D_ENUM(name, lower, upper, type) ...
> # define D_ENUM_KEY(key, keyLower, keyUpper, type, typeLower, 
> typeUpper) ...
>
> And then the header emits:
> D_ENUM(DEnum, denum, DENUM, int)
> {
>   D_ENUM_KEY(MyKey, mykey, MYKEY, DEnum, denum, DENUM),
> }
>
> This allows maximum flexibility! It can support the D compilers 
> weird naming strategy without adding additional options to the 
> compiler.

That's a pretty neat hack!

I'm just worried about two things:
- it makes the generated code harder to read (not that big of a 
deal)
- if you happen to include headers with conflicting D_ENUM* 
defines (e.g. a potential 3rd party D wrapper), you might get 
some nasty surprises :/