Enums to strings

[Steve Lime]

Fine by me. I'll take care of the conversion. Where should the lookup functions live? I'd propose mapfile.c...

Steve

>>> Daniel Morissette <dmorissette at dmsolutions.ca> 09/19/05 9:09 PM >>>
I like the idea of keeping the strings as close as possible to the enum 
in the .h file to help maintenance. How'bout the following approach that 
uses a #define to keep the strings close to the enum in the header file?

In map.h:

enum MS_UNITS {MS_INCHES, MS_FEET, MS_MILES, MS_METERS, MS_KILOMETERS, 
MS_DD, MS_PIXELS, _MS_UNITS_COUNT};
#define MS_UNITS_STRINGS {"inches", "feet", "miles", "meters", 
"kilometers", "dd", "pixels"}


Then the lookup function would be implemented as:

static char **msGetUnitsStrings(int code)
{
     static char **values = MS_UNITS_STRINGS;
     if (code >= 0 && code < _MS_UNITS_COUNT)
         return values[code];
     else
         return "unknown";
}

Daniel


Steve Lime wrote:
> Option number 2 it is then (with unknown)...
> 
> 
>>>>Frank Koormann <frank.koormann at INTEVATION.DE> 09/17/05 8:40 AM >>>
> 
> Dear all,
> 
> * Frank Warmerdam <warmerdam at POBOX.COM> [050917 05:53]:
> 
>>On 9/16/05, Steve Lime <steve.lime at dnr.state.mn.us> wrote:
>>
>>>I was thinking of just parking the array of strings right next to the enum in map.h, but the function sounds fine too. Were you thinking of something like:
>>>
>>>static char **msGetUnitsStrings()
>>>{
>>>  static char **values = ...;
>>>  return values;
>>>}
>>>
>>>or something like:
>>>
>>>static char *msGetUnitsString(int code)
>>>{
>>>  switch (code) {
>>>    case 0: return "meters";
>>>    case 1: return "feet";
>>>      ...
>>>   }
>>>
>>>   return NULL;
>>>}
>>>
>>>The last element being the count is a good idea. We're doing that with the error codes in maperror.h but no where else I believe.
>>
>>Steve,
>>
>>Either way works, but the (very small) advantage of the second is that
>>it is easier to convert a enum code into a string into the middle of
>>an expression, such as the arguments to a debug or error message.
> 
> 
> just a thought since the original need for this function has been template 
> processing: The second option also would allow to add i18n in the furture.
> 
> Regards,
> 
>         Frank Koormann