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.
Haut de la page
Les messages affichés proviennent d'usenet.
NewsPortal