enum values to strings.

[Neil Williams]

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 
future.

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,)        \
 _(hotsync,)
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 
line!

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
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- 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