"Paul Mensonides" <pmenso57@comcast.net> writes:
-----Original Message----- [mailto:boost-bounces@lists.boost.org] On Behalf Of David Abrahams
"Vesa Karvonen" <vesa_karvonen@hotmail.com> 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