enum values to strings.

[Christian Stimming]

Hi Neil,

Am Donnerstag, 24. März 2005 22:32 schrieb Neil Williams:
> Can anyone see problems with this solution? Are the defines correct C?

One C-problem the defines run into is the extra "," (comma) at the end of the 
enum lists. 

> typedef enum { RED = 0, GREEN = 1, BLUE = 87, }Color;

I recall that with some compiler warning settings, you will get a warning for 
this, and that would make -Werror useless. However, that might be a rather 
small issue.

As Derek said, the idea is nice, but since we already have covered most such 
cases of interest in gnucash with "normal code", I wouldn't change those 
existing solutions.

> const char* asString(Color n) {
>   switch (n) {
>      case RED:      return "RED";
>      case GREEN: return "GREEN";
>      case BLUE:    return "BLUE";
>      default: return "";
>    }
> }

Note that your asString( ) function contains a default-clause in the switch 
statement. You might consider removing that one. Then, some compiler warning 
settings will actually issue a warning if you forgot any of the potential 
enum values, which is a quite effective measure to check that you've really 
covered all cases. That's important if you're using the manually created 
mapping functions, as gnucash currently does, and in that case it's also 
sufficient as a reminder if you added any enum values.

> Should the strings be translatable?
> #define AS_STRING_CASE(name, value) \
>     case name: return _(#name);
> instead of return #name?

NOT AT ALL! Enum values are source-code level things (and the string values 
for these as well), but gettext translations are for user-visible things. 
Those two should never be confused. If you want a mapping of enum values to 
user-visible strings, you would have an additional function, which will then 
also use the gettext translations. But your mappings (I'd prefer that term, 
in order not to confuse it with the user-visible gettext translations) are 
not at all user-visible.

Christian