jak@cs.brown.edu (Jak Kirman) (12/29/90)
I have a problem concerning the expansion of a macro use within a macro
use. The problem is not an academic one; I am trying to write a
parameterized associative list package using a parameterized list
package, but to simplify this posting I will use a toy example.
I find myself needing to use nested macros in the following way:
#define first(a) name2(one,a)
#define second(b) name2(two,b)
second(first(x))
I would like this to expand in the same order that a C++ compiler would
look at a function call: the "argument" first.
So I would like first(x) to expand to onex, and then second(onex) to
expand to twoonex.
Using the Gnu C preprocessor, I get exactly what I want. Using the AT&T
C++ 2.0 compiler, using the default preprocessor /lib/cpp -B, the macro
second is expanded, producing twofirst(x). The preprocessor can then no
longer expand first(x), since it is not a token. Sun's 2.1 compiler
does exactly the same thing, presumably using the same preprocessor.
Which of these two behaviours is correct? I couldn't find anything
appropriate in Ellis & Stroustrup.
Thanks.
Jak jak@cs.brown.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It was loud in spots and less loud in other spots, and it had that
quality which I have noticed in all violin solos of seeming to last much
longer than it actually did.
-- P.G. WodehouseInvader@cup.portal.com (Michael K Donegan) (01/03/91)
There is another possible interpretation, you could get twoname2(x) second(first(x)) => name2(two,first(x)) => two ## name2(one,x) => twoname2(one,x) It really depends on whether the first(x) expansion is done in isolation or not. On page 374 of ARM it says "If a ## operator appears in a replacement token sequence between two tokens..." Now the ## appears between two and name2, but are we to consider the entire replacement token sequence or just the one being currently expanded? I think that your interpretation is the most likely one. It is what Think C does. mkd