Date: Mon, 8 Feb 2021 21:58:37 +0100
Joseph,
on Mon, 8 Feb 2021 20:46:29 +0000 you (Joseph Myers
<joseph_at_[hidden]>) wrote:
> On Mon, 8 Feb 2021, Jens Gustedt via Liaison wrote:
>
> > Hi,
> > just to give the discussion on
> >
> > > P2264R0 (http://wg21.link/p2264r0) Make assert() macro user
> > > friendly for C and C++
> >
> > a start. For me, the paper by itself is a no-brainer, `assert`
> > should have been `...` from the beginning, for all the reason that
> > are given in the paper.
>
> I think it's peculiar to do something just for assert and not for any
> other standard library macro (or, in C, almost any standard library
> function, as those could be defined as macros) that could be passed
> an argument involving a comma not inside parentheses (e.g. in a
> compound literal).
>
> 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.
> 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).
> > (2) Currently, not passing a scalar expression is only UB and not a
> > constraint violation. This looks weird to me. Generally we could
> > have a new constraint section that says something like:
>
> Constraint violations are generally problematic for macros; when
> arbitrary pp-token sequences can be passed as arguments, it's hard to
> ensure that the result of the expansion generates a constraint
> violation at the language level for every pp-token sequence not
> intended to be valid in that context, without having some language
> extension very specific to the exact constraint to be checked.
Here it is not problematic at all. You just have to use a ... list and
put it into a
((bool)(__VA_ARGS__))
So any compiler that has no idea on how to convert the expression into
`bool` should cry out loud.
Jens
on Mon, 8 Feb 2021 20:46:29 +0000 you (Joseph Myers
<joseph_at_[hidden]>) wrote:
> On Mon, 8 Feb 2021, Jens Gustedt via Liaison wrote:
>
> > Hi,
> > just to give the discussion on
> >
> > > P2264R0 (http://wg21.link/p2264r0) Make assert() macro user
> > > friendly for C and C++
> >
> > a start. For me, the paper by itself is a no-brainer, `assert`
> > should have been `...` from the beginning, for all the reason that
> > are given in the paper.
>
> I think it's peculiar to do something just for assert and not for any
> other standard library macro (or, in C, almost any standard library
> function, as those could be defined as macros) that could be passed
> an argument involving a comma not inside parentheses (e.g. in a
> compound literal).
>
> 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.
> 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).
> > (2) Currently, not passing a scalar expression is only UB and not a
> > constraint violation. This looks weird to me. Generally we could
> > have a new constraint section that says something like:
>
> Constraint violations are generally problematic for macros; when
> arbitrary pp-token sequences can be passed as arguments, it's hard to
> ensure that the result of the expansion generates a constraint
> violation at the language level for every pp-token sequence not
> intended to be valid in that context, without having some language
> extension very specific to the exact constraint to be checked.
Here it is not problematic at all. You just have to use a ... list and
put it into a
((bool)(__VA_ARGS__))
So any compiler that has no idea on how to convert the expression into
`bool` should cry out loud.
Jens
-- :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS ::: :: ::::::::::::::: office Strasbourg : +33 368854536 :: :: :::::::::::::::::::::: gsm France : +33 651400183 :: :: ::::::::::::::: gsm international : +49 15737185122 :: :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
Received on 2021-02-08 14:58:43