Boost logo

Boost :

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

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at