From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2004-06-11 19:50:05
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
> > To the macro expansion mechanism, there are two main categories of
> > preprocessing tokens--functional and non-functional.
>
> Yeah I know, but I would never use those terms; too easily
> confused with function-like and object-like macros.
Yeah, maybe preprocessing tokens that have syntactic/semantic effect.
> > The functional preprocessing tokens are comma and the left
> and right
> > parentheses. All others are non-functional (as input to
> macros). You
> > have to be careful whenever you pass preprocessing tokens that are
> > "functional" as arguments because they can have syntactic/semantic
> > effect. Also note that an unmatched parenthesis can be considered
> > pathological input. It is only possible to pass such a
> token by the
> > use of a macro expansion, as in MACRO(LPAREN()). Unmatched
> > parentheses in particular should
> > *never* be passed to pp-lib primitives.
>
> Even via LPAREN()? -- not that I'm going to reveal these
> details to people. I'm just telling them that unmatched
> parens can never be macro arguments.
LPAREN() can be used to create a left parentheses, and thus can be used to pass
an unmatched left parentheses to a macro. That indirection is the only way to
do that. However, it is inherently dangerous because the "argument-ness" of it
cannot be preserved--it interferes:
#define LPAREN() (
#define A(x) x
#define B(x) A(x)
A(LPAREN()) // okay, expands to: (
B(LPAREN()) // error: unmatched parenthesis
However, you can pass the macro name LPAREN itself as as argument, provided it
isn't later invoked in a context which would cause the above situation
internally. There are valid reasons to programmatically create left and right
parentheses.
Regards,
Paul Mensonides