Date: Mon, 8 Feb 2021 21:50:38 +0000
On Mon, 8 Feb 2021, Jens Gustedt via Liaison wrote:
> > The __VA_ARGS__ trick only works for macros with a single argument.
>
> Not completely true. I works as long as the interesting one the last
> macro argument.
I think most standard function-like macros (and all
functions-that-can-be-macros) have expresions for all arguments, meaning
any of them could involve a compound literal. There are very few
exceptions where an argument is not an expression (e.g. va_arg, offsetof -
and the first argument of va_arg is an expression).
> > Defining a new style of macro that takes balanced token sequences and
> > ignores commas inside [] or {} would suffice for C, but it's less
> > clear how that could work for C++.
>
> I don't think that this is necessary, even. There are not so many
> features that are defined as first-class function-like macros. We
> could look at them in a case-by-cass basis (There is a handfull, I
> think.)
>
> For all others, replacement of functions by function-like macros, we
> have the general fallback, anyhow, that says something like that they
> must be callable in any context where the function can be used (or
> so).
The general fallback refers to "fully protected by parentheses where
necessary". I don't think it's intending to allow anything that would not
work with a routine #define that names each argument and surrounds them
with () in the expansion.
> > The __VA_ARGS__ trick only works for macros with a single argument.
>
> Not completely true. I works as long as the interesting one the last
> macro argument.
I think most standard function-like macros (and all
functions-that-can-be-macros) have expresions for all arguments, meaning
any of them could involve a compound literal. There are very few
exceptions where an argument is not an expression (e.g. va_arg, offsetof -
and the first argument of va_arg is an expression).
> > Defining a new style of macro that takes balanced token sequences and
> > ignores commas inside [] or {} would suffice for C, but it's less
> > clear how that could work for C++.
>
> I don't think that this is necessary, even. There are not so many
> features that are defined as first-class function-like macros. We
> could look at them in a case-by-cass basis (There is a handfull, I
> think.)
>
> For all others, replacement of functions by function-like macros, we
> have the general fallback, anyhow, that says something like that they
> must be callable in any context where the function can be used (or
> so).
The general fallback refers to "fully protected by parentheses where
necessary". I don't think it's intending to allow anything that would not
work with a routine #define that names each argument and surrounds them
with () in the expansion.
-- Joseph S. Myers joseph_at_[hidden]
Received on 2021-02-08 15:50:46