Sujet : Re: "A diagram of C23 basic types"
De : david.brown (at) *nospam* hesbynett.no (David Brown)
Groupes : comp.lang.cDate : 02. Apr 2025, 10:33:17
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vsj08u$1gaus$1@dont-email.me>
References : 1 2
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
On 02/04/2025 09:02, Janis Papanagnou wrote:
On 02.04.2025 07:59, Alexis wrote:
>
Thought people here might be interested in this image on Jens Gustedt's
blog, which translates section 6.2.5, "Types", of the C23 standard
into a graph of inclusions:
>
https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
A nice overview. - I have questions on some of these types...
The _Decimal* types - are these just types with other implicit
encodings, say, BCD encoded, or some such?
The nullptr_t seems to be a special beast concerning the "NULL"
entity; what purpose does that type serve, where is it used?
"nullptr_t" is the type of "nullptr". And "nullptr" is always a null pointer constant, just like the literal "0". But unlike "0", it can never be mistaken for an integer - thus compilers will be able to detect mistakes more easily. Consider the three basic ways of specifying a null pointer, and how they can be converted to an integer:
int * p = 0;
int * q = NULL;
int * r = nullptr;
int a = 0; // No complaints from the compiler!
int b = NULL; // Usually an error
int c = (int) NULL; // No complaints
int d = nullptr; // Error
int e = (int) nullptr; // Error
int f = (int) (void*) nullptr; // You really mean it!
This is what makes "nullptr" safer, and thus a useful addition to C. It is also consistent with C++, where "nullptr" is more important (for use in function overloads).
The type "nullptr_t" itself is unlikely to be particularly useful, but has to exist because "nullptr" needs a type. It could conceivably be used in a _Generic, but I have not seen any applications of that.
I see the 'bool' but recently seen mentioned some '_Bool' type.
The latter was probably chosen in that special syntax to avoid
conflicts during "C" language evolution?
Yes. The tradition in C has been that added keywords have had this _Form, since that type of identifier is reserved. Thus between C99 (when _Bool was added) and C17, the type was named "_Bool", and the header <stdboolh> contained:
#define bool _Bool
#define true 1
#define false 0
For C23, it was decided that after 20-odd years people should be using the standard C boolean types, and thus the type was renamed "bool" (with "_Bool" kept as a synonym), and "true" and "false" became keywords. <stdbool.h> is now basically empty (and unnecessary) in C23 mode, but of course still exists for compatibility.
How do regular "C" programmers handle that multitude of boolean
types; ranging from use of 'int', over own "bool" types, then
'_Bool', and now 'bool'? Since it's a very basic type it looks
like you need hard transitions in evolution of your "C" code?
For anything that is not hampered by ancient legacy code, you use :
#include <stdbool.h>
bool a = false;
bool b = true;
That applies from C99 up to and including C23 - though if your code is definitely C23-only, you can happily omit the #include.
For pre-C99 code that uses home-made boolean types, it is common in reusable code (such as libraries) for the types and everything else to be prefixed - "MYLIB_boolean", etc. But some code might use the names "bool", "true" and "false" with their own definitions. If those are #define definitions, the code will probably work much as before though it is technically UB, but if they are typedefs, enums, etc., they cannot be compiled as C23.