Re: [boost] [preprocessor] "How macro expansion works", comments

From: Tobias Schwinger (tschwinger_at_[hidden])
Date: 2006-02-17 05:30:36

Paul Mensonides wrote:
>  
>>>I don't know.  It is fairly cause-and-effect.  If you use the 
>>>stringizing operator in a nullary function-like macro, it 
>>
>>is an error.  
>>
>>>For the same reason, if you use the stringizing operator in a 
>>>non-nullary function-like macro without applying it to an 
>>
>>instance of a formal parameter, it is an error.
>>
>>No strong opinion, here. But while we're at it -- what about
>>
>>     # define CHAOS_IP_HASH_I #
>>
>>? 
> 
> 
> It isn't a function-like macro.  In an object-like macro, there is no
> stringizing operator.  

Fine. Brings me back to the text. This detail is woth mentioning! 

"There is no stringizing operator for object-like macros" is certainly less clear than "the '#' character in an object-like macro does not act like an operator and is passed on to the output" (or so).

>>>>I have to clarify: I'm missing a hint (in the text not the
>>>>examples) that tokens from outside the replacement list can form a 
>>>>macro invocation together with expansion output. The sentence from 
>>>>16.3.4-1 is actually quite good.
>>>
>>>
>>>I think that any need for this (i.e. such a hint) is symptomatic of 
>>>trying to view macros like functions (e.g. F calls G, G 
>>>returns 1 to 
>>>F, F returns 1 to whatever called F).  I'm in favor of 
>>>doing anything 
>>>that I can do to eradicate this preconception.
>>
>>I disagree.
>>
>>If you don't want people to think of macros as functions it's 
>>important to point out the differences as clear as possible.
> 
> 
> There is a section on that alone.  There is also a section on interleaved
> invocations--which is about macro invocations that span the end of replacement
> list.
> 
> 
>>It's quite easy to come up with a simple and stupid text 
>>replacement mechanism that does *not* have this behaviour 
>>without wasting a single thought on functions.
> 
> 
> Yes.  However, in such a language, whether or not "macro invocations" form a
> functional hierarchy or not is irrelevant because the result is the same.
> 

Fair enough ;-).

> 
>>>At the same time, it is worth noting that the syntax of macro 
>>>invocations is dynamic.  That is, a series of macro 
>>>invocations cannot 
>>>be parsed into a syntax tree and then evaluated.  It can only parse 
>>>one invocation at a time, and its result is basically
>>>appended to the input.

Replacing 'appended' with 'prepended' makes this sentence a really usable explanation of what the standard calls "rescanning".

>>
>>The terms 'invocation' and 'function-like macro' are probably 
>>much worse than wasting some words on how dynamic things really are...
> 
> 
> I'm not sure I follow what you're saying here.  Can you rephrase?
> 

After we have done a expansion we have to reset our scanner back to the first token in the replacement list. 

That's what "rescanning" means to me. "The output is prepended to the input" (or so) is probably a better way to say it. Anyway, some redundancy to highlight this process is a good thing because it explains the dynamic nature of the preprocessor's syntax.

The terms "invocation" and "function-like macro", however, are pushing the reader towards viewing macros as functions (worse than "rescanning" does IMO).

Regards,

Tobias