rbutterworth@watmath.UUCP (Ray Butterworth) (01/15/87)
> From: gwyn@brl-smoke.ARPA (Doug Gwyn ) > Subject: Re: RMS comments to X3J11 (LONG) > Date: 8 Jan 87 15:56:56 GMT > > >2. A preprocessor directive that allows defining a macro so > >that each time it is called it appends some text to the definition > >of another macro. > > I thought this could be done with the defined facilities. Which defined facilities are those? They aren't available in the cpp here. How does one write an ANSI macro X(a,b,C) that appends "a" to macro A and "b" to macro "B and "a b" to macro C? (Actually what would also be nice is a way of incrementing a symbol from within a macro. It would be useful for generating unique labels and such things.)
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/17/87)
In article <4430@watmath.UUCP> rbutterworth@watmath.UUCP (Ray Butterworth) writes: >> From: gwyn@brl-smoke.ARPA (Doug Gwyn ) >> Subject: Re: RMS comments to X3J11 (LONG) >> >2. A preprocessor directive that allows defining a macro so >> >that each time it is called it appends some text to the definition >> >of another macro. >> I thought this could be done with the defined facilities. >Which defined facilities are those? They aren't available in the >cpp here. How does one write an ANSI macro X(a,b,C) that appends >"a" to macro A and "b" to macro "B and "a b" to macro C? Well, it isn't possible according to the rules to change the formal definition (replacement list) of a macro as a side-effect of macro expansion, for the following reasons: (1) non-benign redefinition is prohibited; (2) #undef doesn't help because macro expansion doesn't trigger additional preprocessor control actions. There are fairly good reasons for insisting on these constraints. What I had had in mind was an equivalent solution (done as more than one preprocessor control action) such as: #define TMP NAME #undef NAME #define NAME TMP ## new_stuff #undef TMP but I should hasten to point out that this idea was a mistaken notion on my part, because replacement is done when a macro is invoked, and only the latest definitions would still be "known" at that time. I apologize if I misled anyone. I suppose the important point is that C preprocessing is NOT a general-purpose macro facility such as M4. To be one, it would need to support recursion during macro replacement, either an "eval" or a "quote" operator, non-benign redefinition, and other things that never were considered to be permissible for C preprocessing a la K&R. Perhaps a future language ought to consider mandating a general macro facility; I agree that it would be useful to have one.