3 ms·
Interesting stuff! Here are my notes: - decl.qualified-return-type is comparing two very different syntaxes: a common C __typeof__ extension versus C++ decltyp
by ludocode 4y ago
Interesting stuff! Here are my notes:
- decl.qualified-return-type is comparing two very different syntaxes: a common C __typeof__ extension versus C++ decltype. This is hardly an example of code that compiles differently since it's compiling different code. In any case, there is a C23 proposal for typeof() which notes that it intentionally does not behave as C++ decltype(). It proposes an alternate syntax which might be called something like remove_quals() or typeof_unqual(). It will behave closer to C++ decltype() but still not the same because it will remove _Atomic and restrict which do not exist in C++.
- In stmt.decl-after-label, C23 will additionally allow a label at the end of a block. C++ does not. So they will still not match after C23 :). You need to put a null statement (a semicolon) after a label at the end of a block to make it portable.
- type.char8_t-literal will fixed by C23. char8_t will be a typedef to unsigned char and u8"" string literals will have type unsigned char[].
- In decl.empty-initializer, the C++ syntax will be supported in C23.
- expr.inc-dec-bool says ++ and -- do not invert the _Bool value. Is this implying that they do nothing? Because if so it does not match my tests. They behave as though +1 or -1 were applied to the value as an int, but then it is cast back to _Bool, so -- on 1 produces 0 and all other cases produce 1 (including -- on 0.) https://godbolt.org/z/f4Gvbqhbd https://godbolt.org/z/f4Gvbqhbd
- jwilk 4y ago"x++" is not equivalent to "x = !x", which is probably what they meant. OTOH, as you noted, "x--" does the right thing.
- turndown 4y ago>- In stmt.decl-after-label, C23 will additionally allow a label at the end of a block. C++ does not. So they will still not match after C23 :). You need to put a null statement (a semicolon) after a label at the end of a block to make it portable. This actually isn't true, there is a small change to the standard that has been approved for C++23 to keep the grammars in sync on this. See here: https://github.com/steve-downey/papers/blob/master/wg21-status.org#p2324-labels-at-the-end-of-compound-statements-c-compatibility-martin-uecker https://github.com/steve-downey/papers/blob/master/wg21-stat...