Patrik Stridvall wrote:
Not really, but as an alternative solution you could has a structure instead of an array like:
typedef struct { GLYPHNAME A; GLYPHNAME AE; GLYPHNAME AEacute; GLYPHNAME AEsmall; /* ... */ } GLYPHNAMES;
Perhaps this is better since it doesn't use the preprocessor.
I not thought of that -- neat idea. What is the downside of using the preprocessor, however?
Well, the preprocessor "pollutes" the namespace in a way that is sometimes bad and my solution gives IMHO a slightly nicer syntax.
Is this case in don't think it matters so much though, your orginal solution is fine, in fact is the standard solution in C to the problem you have AFAIK.
My suggestion is really just brainstorming to give you hopefully a different perspective of the issue. Also note that your solution is not possible with languages that don't have pointer aritmetics that C, fortunately or unluckily depending on how you see it, have.
At 11:32 PM 7/19/01 +0200, Patrik Stridvall wrote:
Patrik Stridvall wrote:
Not really, but as an alternative solution you could has a structure instead of an array like:
typedef struct { GLYPHNAME A; GLYPHNAME AE; GLYPHNAME AEacute; GLYPHNAME AEsmall; /* ... */ } GLYPHNAMES;
Perhaps this is better since it doesn't use the preprocessor.
I not thought of that -- neat idea. What is the downside of using the preprocessor, however?
Well, the preprocessor "pollutes" the namespace in a way that is sometimes bad and my solution gives IMHO a slightly nicer syntax.
Yeah, this is true that preprocessor directives "pollute." In this case, though, I agree with both of you that it is an acceptable solution. It actually takes advantage of preprocessing in that it takes the work load off of run-time creation of a dynamic table and puts it on the compiler so it only has to be done once. They're often overused, but they can be helpful in some cases.
- Brandon
-
Brandon Kilgore -
Patrik Stridvall