Replying to
...while keeping ..nation/states.. dubless at fraudulent/false scientific experimentation all different for deferment of stay...
On Apr 8, 2021, at 6:14 AM, via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Dear all,
I am somewhat unhappy with P2264R0. Its main goal is to make it more beginner friendly. However, it introduces a pitfall for beginners that is currently not present.
The paper suggests to define basicallyCertainly, it makes#define assert(...) ((__VA_ARGS__)?(void)0:std::abort())assert(std::is_same::value);working as expected, which is good. However, a beginner might think that assert works like static_assert and writeassert(std::is_same::value, "Different types");If P2264R0 gets adopted, this becomes a well-formed. And the assertion will pass since a string literal is not NULL. Currently such a code is ill-formed, which is much better.
An alternative would be to definesince a function style cast does not allow a comma operator. In this case,#define assert(...) (bool(__VA_ARGS__)?(void)0:std::abort())assert(std::is_same::value);would work as expected andassert(std::is_same::value, "Different types");would still be ill-formed.
The example from P2264r0looks like an anti-pattern to me. Particularly after deprecating the comma operator in subscript expressions, it is very odd if it gets newly introduced into the assert macro. If WG21 accepts P2264r0 as-is into the standard and if programmers start using this comma operator trick (since it would be an allowed use), the above-mentioned pitfall will be stuck in the language forever.assert((void)"this cannot be true", -0.0);
PS: I have tried to post this e-mail some time ago, but apparently there was a problem.
Best regards,
StefanIhr Recht auf Privatsphäre. Schützen Sie Ihre Daten und wechseln jetzt zu eclipso Mail & Cloud.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
