When printing an enum value in debugging mode, distinguish between
bitsets containing flags and ordinary enums that just contain different
values.
Make the macros in enum.h more uniform. Provide a simple scheme for
defining the run-time type information of enums whose number of values
is a number with more than 2 bits set in the binary representation.
This case was not obvious before, and it was pure luck that the current
interesting enum types only had 3, 10 or 32 different values.
The type with the 32 different values actually only has 31 significant
bits since the enum constant OP_OPMASK is only used when querying the
enum, not for defining or describing the possible values. For this
reason, it was unavoidable to refactor the rtti macros, to support even
this case.
A string like OP_DEPENDS|OP_OPTIONAL|OP_PRECIOUS is much easier to read
and understand than the bit pattern 00000089.
The implementation in enum.h looks really bloated and ugly, but using
this API is as simple and natural as possible. That's the trade-off.
In enum.h, I thought about choosing the numbers in the macros such that
it is always possible to combine two of them in order to reach an
arbitrary number, because of the "part1, part2" in the ENUM__SPEC macro.
The powers of 2 are not these numbers, as 7 cannot be expressed as the
sum of two of them. Neither are the fibonacci numbers since 12 cannot
be expressed as the sum of 2 fibonacci numbers. I tried to find a
general pattern to generate these minimal 2-sum numbers, but failed.
Declaring the ToStringSize as "static const size_t" made it an ordinary
integer expression. To avoid variable length arrays, the commonly
accepted way is to declare the length as an enum constant, as that is
considered an integer constant expression, which in turn makes the
declaration a fixed-size array.
Before a modifier is applied to a variable, it is not yet parsed,
therefore it is only possible to log a rough estimate of the modifier.
But after applying it, the parsing position has advanced, and the full
modifier can be logged.
In addition, to fully understand how the modifiers work, it's not enough
to just know the variable names and values, there are also some flags
that influence how the modifiers behave. The most influential is
VARE_WANTRES.
Thanks to sjg for the extensive review and valuable feedback on the
first drafts.
