-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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