Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!rutgers!usc!wuarchive!uunet!mtndew!friedl From: friedl@mtndew.Tustin.CA.US (Steve Friedl) Newsgroups: comp.lang.c Subject: Re: Is this bad programming? Keywords: #define array definition Message-ID: <499@mtndew.Tustin.CA.US> Date: 19 Aug 90 17:07:37 GMT References: <1990Aug8.100614.1223@resam.dk> <1990Aug9.054556.22271@athena.mit.edu> Organization: VSI*FAX Tech Ctr, Tustin, CA Lines: 41 Steve Summit writes: > [Others] worry about keeping error numbers in sync with an array of > error message strings so that the array can be indexed by the > array number. > > Whenever I'm serious about making the connection between error > numbers and messages explicit rather than implicit, I do so > quite, er, explicitly: > > #define FILE_FOOTER_ERROR 1 > #define DRAW_FOOTER_ERROR 2 > > struct errmess { int em_number; char *em_text; } errmesses[] = > { FILE_FOOTER_ERROR, "File footer error", > DRAW_FOOTER_ERROR, "Draw footer error", > ... }; [ style compressed by me ] I occasionally have to do this kind of thing for a case where I must access the array repeatedly, and the search time is more than I care to allow. So, I define a table just as Steve does above, then define an auxilliary table of pointers to these structs that I build at runtime. This way I can lay out the table in no particular order, and the runtime sorter stuffs in all the relevant values (including a pointer to a single static "dummy" value for holes in the array). It does require a hit at runtime, but it means that I can do things like an array of signal names without having to do a *horrible* #ifdef dance that depends on my knowing which signal numbers have which values. I have seen people try to build these tables for multiple machines, and in my opinion it is ridiculous to try to do so. Steve -- Stephen J. Friedl, KA8CMY / Software Consultant / Tustin, CA / 3B2-kind-of-guy +1 714 544 6561 / friedl@mtndew.Tustin.CA.US / {uunet,attmail}!mtndew!friedl Combat global warming -- leave the refrigerator door open