enum values to strings.

Neil Williams linux at codehelp.co.uk
Thu Mar 24 18:35:31 EST 2005

On Thursday 24 March 2005 9:41 pm, Derek Atkins wrote:
> Note that in many cases this conversion is already done. The Gnucash XML 
> does this in most cases.  Take a look at, e.g. src/engine/Account.c for an
> example. It's not _quite_ as clever as your code, but it does the job.

(I wish that had been documented with Doxygen!) I knew it had to exist, just 
couldn't find it!

AFAICT, the advantage is:
The larger macro removes the need to have two separate functions in tandem. 
Only the ENUM_LIST needs to be edited to add or remove values - it's more 
like the underlying enum itself. That should make for easier changes in 

I've amended the macro to remove the need to specify EVERY enum value. Using 
the syntax:
#define ENUM_BODY(name, value)     \
    name value , 
(note the behaviour of the space and the comma!)

#define ENUM_LIST(_)       \
 _(noop, = 0)    \
 _(offline,)        \
offline is given the enum value 1 and hotsync is 2. 
Note the comma between the name and the equals sign *and* at the end of each 

Is that workable? Is it worth using it *in place of* the existing macros to 
ease future development? Use just for enums not already covered?

Why, in Account.c, are the current macros undefined after the function 
declaration? I was thinking of defining the main macros just once in one of 
the header files in /src/engine - are there issues with scoping / duplicates 
that can't be resolved as you would normally with header files?

Only the ENUM_LIST macro would be defined in the main source, once per enum. 
(It doesn't have to be called ENUM_LIST either if that's a problem, each enum 
can have their own.)

The only drawback that I've found so far:
Doxygen needs the values to be repeated if you are going to document the enum 
values. Currently Doxygen documents the ENUM_LIST define not the enum and the 
macro removes any /**< */ constructs.

> And yes, we should definitely be using strings instead of ints for enums.
> Remember when I asked why you needed QOF_TYPE_INT32?  ;)

Yes, I do. 

> I dont think we ever use an INT64 enum.

I can't see that being used either.


Neil Williams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050324/a77e617d/attachment.bin

More information about the gnucash-devel mailing list