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 http://www.boost-consulting.com