Am Montag, 6. Juni 2011 schrieb Tim M:
> I can remove the comma from the ENUM_BODY and instead put it in the
> LOG_LEVEL_LIST define like this:
>
> #define ENUM_BODY(name, value) \
> name value
>
> #define LOG_LEVEL_LIST(_) \
> _(QOF_LOG_FATAL, = G_LOG_LEVEL_ERROR), \
> _(QOF_LOG_ERROR, = G_LOG_LEVEL_CRITICAL), \
> _(QOF_LOG_WARNING, = G_LOG_LEVEL_WARNING), \
> _(QOF_LOG_MESSAGE, = G_LOG_LEVEL_MESSAGE), \
> _(QOF_LOG_INFO, = G_LOG_LEVEL_INFO), \
> _(QOF_LOG_DEBUG, = G_LOG_LEVEL_DEBUG)
>
> This change prevents the make warning/error, ...
I agree with your change here. From what this twisted interleaving of macros
should look like, the comma should be set as you say and not as the current
macros would do. If they make eclipse break, well, we probably can fix this
for now.
But in general: I don't see the value of those macros here anyway. I mean, the
list of enum values need to appear in the definition of LOG_LEVEL_LIST anyway.
Passing this list through two other macros doesn't really save any typing
except for the two words "typedef enum { ... }". The macros might have made a
little bit of sense if it were for a unified generation of some wrapper
function (e.g. the conversion functions from and to string)... oh, I see: Some
of the enum declaration actually use those: AS_STRING_DEC, AS_STRING_FUNC,
FROM_STRING_DEC, FROM_STRING_FUNC.
It's a classical tradeoff between saving of typing and making the code less
readable: IMHO it is a big disadvantage that those functions are hidden behind
this non-understandable macros. Because of that, I would rather prefer writing
all the declaration and also those conversion functions in plain text instead
of hiding them behind macros.
But in any case, those enums which don't use the conversion functions also
don't need to use the DEFINE_ENUM macro. Hence, feel free to submit a patch
that replaces DEFINE_ENUM by a normal declaration for all enums which don't
use the conversion function macros. Thanks!
Christian
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
