You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While C's int*_t/uint*_t aliases are nice, they are (in my opinion) a band-aid over the real problem which is that the entire language was built over a foundation of implementation-defined fundamental types rather than universally understood fixed-width types. C++ inherits this mistake.
One example of a negative consequence that resulted from this decision is the lack of a proper 8-bit integer type. There's int8_t but this is typically implemented as an alias for char, which can cause unexpected issues in C++ such as trying to print an int8_t but it instead being printed as a char would. And std::byte doesn't help because it is an enum which lacks the normal operations integer types have.
Now, if C++ adopts C23's language features including _BitInt(N), Cpp2 may have to opportunity to use it in its shortened aliases for fixed-width integer types. The following would be valid in both C and C++:
This could potentially for the first time provide proper fundamental types to C and C++, including an 8-bit integer type which is actually an 8-bit integer type, while also using the optimal shortened names.
These _BitInt(N) types can implicitly convert to and from their fixed-width equivalents in <cstdint> which would help make their usage easier. Unfortunately there would be some unsettled issues regarding their usage in existing generic code which wasn't written with _BitInt(N) in mind, though a cast to its corresponding int*_t/uint*_t type could be used where needed.
_BitInt(N) also carries the property that they do not follow integer promotion rules, which may be desirable. Or not? I do not know.
There are likely other issues with this proposal that I haven't thought of yet, but I'd like to see what people think of it. Could it actually work?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
C23 introduces
_BitInt(N)which is a keyword for specifying bit-precise integer types whereNis the number of bits.See the proposal here: https://open-std.org/JTC1/SC22/WG14/www/docs/n2763.pdf
While C's
int*_t/uint*_taliases are nice, they are (in my opinion) a band-aid over the real problem which is that the entire language was built over a foundation of implementation-defined fundamental types rather than universally understood fixed-width types. C++ inherits this mistake.One example of a negative consequence that resulted from this decision is the lack of a proper 8-bit integer type. There's
int8_tbut this is typically implemented as an alias forchar, which can cause unexpected issues in C++ such as trying to print anint8_tbut it instead being printed as acharwould. Andstd::bytedoesn't help because it is an enum which lacks the normal operations integer types have.Now, if C++ adopts C23's language features including
_BitInt(N), Cpp2 may have to opportunity to use it in its shortened aliases for fixed-width integer types. The following would be valid in both C and C++:This could potentially for the first time provide proper fundamental types to C and C++, including an 8-bit integer type which is actually an 8-bit integer type, while also using the optimal shortened names.
These
_BitInt(N)types can implicitly convert to and from their fixed-width equivalents in<cstdint>which would help make their usage easier. Unfortunately there would be some unsettled issues regarding their usage in existing generic code which wasn't written with_BitInt(N)in mind, though a cast to its correspondingint*_t/uint*_ttype could be used where needed._BitInt(N)also carries the property that they do not follow integer promotion rules, which may be desirable. Or not? I do not know.There are likely other issues with this proposal that I haven't thought of yet, but I'd like to see what people think of it. Could it actually work?
Beta Was this translation helpful? Give feedback.
All reactions