Enums to strings

[Steve Lime]

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

>>> Frank Warmerdam <fwarmerdam at GMAIL.COM> 09/10/05 10:28 AM >>>
On 9/10/05, Steve Lime <steve.lime at dnr.state.mn.us> wrote:
> I've got a request to make available the current units for a map via MapServer templates. No big deal, just add a [mapunits] tag. However, units are an int that needs to be mapped back to a string. The way that's handled for mapfile writing is through a series of static char arrays (in mapfile.c) that are kept in sync with the enums in map.h.
> 
> One solution would be to move those definitions to map.h so they could be generally used. Or should we be considering some other more general approach.

Steve,

Making the list of textual names corresponding to enum lists more broadly
available seems like a good idea.   What I wll suggest is that if the enum
is not "right next" to the list of strings then there should be a comment 
next to the enum pointing to the string list that needs to be updated at the
same time.  That is what I did for the list of TLOCK_ values in mapthread.h
which has a corresponding string list in mapthread.c.  

How were you planning to make the list of strings available in map.h?  As
an "extern char **names;" sort of declaration?  I'm not a big fan of doing
this as it is hard to make these work over DLL boundaries.  What might
be better is a small function that returns the list of names.  Then the list
should either be null terminated, or you could include an "end" marker
in the enum, like I do for this enum.   It makes it easier to know how many
values there are. 

/*! Pixel data types */
typedef enum {
    GDT_Unknown = 0,
    /*! Eight bit unsigned integer */           GDT_Byte = 1,
    /*! Sixteen bit unsigned integer */         GDT_UInt16 = 2,
    /*! Sixteen bit signed integer */           GDT_Int16 = 3,
    /*! Thirty two bit unsigned integer */      GDT_UInt32 = 4,
    /*! Thirty two bit signed integer */        GDT_Int32 = 5,
    /*! Thirty two bit floating point */        GDT_Float32 = 6,
    /*! Sixty four bit floating point */        GDT_Float64 = 7,
    /*! Complex Int16 */                        GDT_CInt16 = 8,
    /*! Complex Int32 */                        GDT_CInt32 = 9,
    /*! Complex Float32 */                      GDT_CFloat32 = 10,
    /*! Complex Float64 */                      GDT_CFloat64 = 11,
    GDT_TypeCount = 12          /* maximum type # + 1 */
} GDALDataType;

> Finallly, do mods like this require an RFC? My initial thought is that if after 
> a quick discussion here it looks like moving the defs from one file to the 
> other is ok, then no the bug would suffice. A more general solution however 
> would necessitate an RFC.

This is a boundary we will need to refine over time.  My feeling is that 
you wouldn't need an RFC for this change as long as your changes
aren't having an effect on other developers or end users.   

Speaking of which, I should likely prepare an RFC for adding various
resampling kernels to the raster code before I go committing it.  

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent