Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-06-11 02:11:47

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

>> -----Original Message-----
>> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
>> "Vesa Karvonen" <vesa_karvonen_at_[hidden]> writes:
>> >>- Fundamental PP Abstractions
>> >> - Macros
>> >> - Non function
>> >> - Function macros
>> >> - Tokens
>> >> - Sequences of tokens not including un-parenthesized commas
> 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.

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

Dave Abrahams
Boost Consulting

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