C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] p2264, assert

From: Jens Gustedt <jens.gustedt_at_[hidden]>
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

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