[Tfug] Developer question

[Bexley Hall]

Greetings!

--- Mike Fitzgibbon <mikef at lpl.arizona.edu> wrote:

> The easiest way I can think of immediately to to
> have a process that will
> parse the enum and then generate the *names array. 
> It would then be
> executed from the Makefile whenever the enum
> changed.  The parser could
> be coded in a scripting language, such as perl or
> tcl, fairly quickly.

Writing it in anything other than C would pose
portabilitiy problems (perl, tcl, etc. aren't
available on all of the development platforms
that I have to support).  And, even in C, it's
a chore as I'd have to count on the OS supporting
a somewhat portable write(3c), etc.

Unfortunately, I can't think of any way *other*
than this to get the job done -- a big WARNING
in the code is almost certain to be overlooked, etc.
:<

> On Mon, 2 Jul 2007, Bexley Hall wrote:
> 
> > A puzzle for lurking developers... :>
> >
> > I have a set of manifest constants that are used,
> > among other things, as indices into different
> > tables.
> >
> > However, to improve the quality of the code,
> > these are implemented as an enumeration.  For
> > a contrived example:
> >
> > enum color_t {
> > 	// By convention, must begin with '0'
> > 	RED = 0,
> > 	GREEN,
> > 	BLUE,
> > };
> >
> > static const char *
> > colornames[] = {
> > 	"Red",
> > 	"Green",
> > 	"Blue",
> > };
> >
> > The head-scratcher lies in coding this in such a
> > way that changes to color_t *automatically*
> > direct the developer to update colornames[].
> >
> > And, to do so at compile-time, *not* run-time!
> >
> > So, for example, adding "BEIGE" to color_t should,
> > at the very least, force a compiler error that
> > is easily/readily recognized as related to the
> > omission of the corresponding "Beige" entry from
> > colornames[].
> >
> > There are some approaches that *approximate* this.
> > For example:
> >
> > #if (sizeof(colornames[]) != COLOR_T_ENTRIES)
> > #  error "colornames[] does not have the correct \
> >    number of color_t entries"
> > #endif
> >
> > except that sizeof() isn't valid during the
> > preprocesor phase (despite having encountered
> > several compilers that don't realize this!  :> ).
> > And, of course, requiring  COLOR_T_ENTRIES to be
> > defined, by convention, as the last entry in the
> > enumeration.
> >
> > So:
> >
> > ASSERT(sizeof(colornames[]) == COLOR_T_ENTRIES)
> >
> > but, this affects (trivially) the TEXT size *and*
> > deferes the test to *run*-time.
> >
> > I can't see a *portable* way of doing this --
> short
> > of writing a tool that writes the code defining
> the
> > table(s), etc.  (and I dislike trusting developers
> > to be diligent -- especially when it comes to
> > maintaining someone else's code  :<  )
> >
> >
> > Extra credit:  a scheme whereby the entries in
> > colornames[] can be assured to correspond to the
> > correct enumeration ordering WITHOUT PENALIZING
> > THE TEXT SIZE!   For example:
> >
> > colornames[RED] = "Red";
> > colornames[BLUE] = "Blue";
> > colornames[BEIGE] = "Beige";
> >
> > would "ensure" the correct entry is associated
> > with each index.  But, it penalizes the TEXT size
> > *and* forces colornames[] to be DATA.  (it also
> > fails to ensure that *all* colornames[] entries
> > are defined).



       
____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/