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

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-02-17 03:48:00

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Tobias Schwinger

> > If the current token is an identifier that refers to a macro, the 
> > preprocessor must check to see if it is painted.  If an identifier 
> > token is painted, it means that the preprocessor will not 
> attempt to 
> > expand it as a macro.  In other words, the token itself is 
> flagged as 
> > disabled and behaves like an identifier that does not 
> correspond to a 
> > macro.  This disabled flag is commonly referred to as "blue paint", 
> > and thus a token that is marked as disabled is called 
> "painted."  (The 
> > means by which an identifier token can become painted is describd 
> > below.)  If the current token is painted, the preprocessor 
> outputs the token and moves on to the next.
> > 
> 
> The paragraph has a *much* better flow now, IMO.

Okay.

> > 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.  That is why it is defined as:

#define CHAOS_PP_HASH() CHAOS_IP_HASH_I
#define CHAOS_IP_HASH_I #

instead of:

#define CHAOS_PP_HASH() # // should be an error

> >>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.

> > 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.
> > 
> 
> 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?

Regards,
Paul Mensonides