Macro Substitution too Complex?
Andrew Choi
c60c-2ca at WEB.berkeley.edu
Sat May 5 11:48:16 AEST 1990
Hi everyone. I thought I understood how macro substituion
works, until I came up with the following example:
Suppose that I have defined the following macros:
#define IMPLEMENT(C, T) C ## _IMPLEMENTATION(T)
#define Apple_IMPLEMENTATION(T) \
implement T ## Apple
#define Orange_IMPLEMENTATION(T) \
IMPLEMENT(Apple, T) \
Apple_IMPLEMENTATION(T) \
implement T ## Orange
/* 1st invocation */
IMPLEMENT(Orange, int)
/* 2nd invocation */
Orange_IMPLEMENTATION(int)
And the results are (after some doctoring)
/* 1st invocation */
IMPLEMENT(Apple, int)
implement intApple
implement intOrange
/* 2nd invocation */
implement intApple
implement intApple
implement intOrange
As you see, in the first instance, IMPLEMENT(Apple, int) is not
expanded, while in the second instance, it is expanded. At
first I thought there may be a level on macro substitution, so I
defined also the following macros:
#define DECLARE(C, T) C ## _DECLARATION(T)
#define Apple_DECLARATION(T) \
declare T ## Apple
#define Banana_IMPLEMENTATION(T) \
DECLARE(Apple, T) \
Apple_DECLARATION(T) \
implement T ## banana
/* 3rd invocation */
IMPLEMENT(Banana, float)
/* 4th invocation */
Banana_IMPLEMENTATION(float)
And the result is (again, after some doctoring):
/* 3rd invocation */
declare floatApple
declare floatApple
implement floatbanana
/* 4th invocation */
declare floatApple
declare floatApple
implement floatbanana
Now this confuses me. They are both the same. If it has something
to do with level, inside the 3rd invocation, the first line should
have read DECLARE(Apple, float) instead. Apparently, this has
nothing to do with the depth of macro substitution.
One possible explanation is that macro substitution is not recursive.
However, is this a standard behavior? Does anyone know the "standard"
rules for performing macro substitution? Is there a "standard"?
Any help or suggestion is GREATLY appreciated.
Andrew Choi
Internet Address: c60c-2ca at web.berkeley.edu
Standard Disclaimer
More information about the Comp.lang.c
mailing list