-1 is not -1 for different sizes of integers. Which exact -1 do you want? 32-bit? 64-bit? int-sized (as int is defined in current implementation)? With current approach it's simple, boolean type is expected to have 1-bit size (which is rounded to 8 bits if stored in memory).
If bool was a signed 1-bit type (i.e. having possible values of either 0 or -1), it could be extended to any size, same as an integer?
Of course we can't have that now, because unsigned bool is baked into the C language standard, and even into processors (x86 SETcc instruction). While "char" being signed or not is still implementation-defined IIRC...
While I understand why C++ defines bool as an Integer, it might have been better if it wasn't. It's not a problem for me that in some modern languages, boolean cannot be mixed with numbers in an expression.
C++ is a true spiritual successor to Perl, in a way. It can express anything and everything, its syntax is arcane, as is its logic. Most of the time, of course, what you see is what you get, until the moment when what you see is what you don't get.
In any field of characteristic 2, every element is its own negative. So on the surface this makes sense, notwithstanding the unintuitive enum corner case behaviour
I wonder if [[=std::bitmask_type]] also enables compiler warnings that a switch statement is not exhaustive if it does not cover all possible flag combinations.
I thought attributes were reserved for compiler-specific semantics like calling conventions. Here they're just being used as stropping for a language feature with syntactic significance!
With such example:
GCC gives a warning if compiling with -Wall:
So, it's surprise that C++ does this, but ones who enable compiler warnings are not in trouble.
They should have defined true as -1 (all bits set) instead, as in some other languages like Forth and BASIC.
-1 is not -1 for different sizes of integers. Which exact -1 do you want? 32-bit? 64-bit? int-sized (as int is defined in current implementation)? With current approach it's simple, boolean type is expected to have 1-bit size (which is rounded to 8 bits if stored in memory).
If bool was a signed 1-bit type (i.e. having possible values of either 0 or -1), it could be extended to any size, same as an integer?
Of course we can't have that now, because unsigned bool is baked into the C language standard, and even into processors (x86 SETcc instruction). While "char" being signed or not is still implementation-defined IIRC...
1 reply →
You have some expectations of the size of the bool (it's simply 1 bit but also 8 bits.)
What expectations do you have of the value?
13 replies →
While I understand why C++ defines bool as an Integer, it might have been better if it wasn't. It's not a problem for me that in some modern languages, boolean cannot be mixed with numbers in an expression.
C++ is a true spiritual successor to Perl, in a way. It can express anything and everything, its syntax is arcane, as is its logic. Most of the time, of course, what you see is what you get, until the moment when what you see is what you don't get.
In any field of characteristic 2, every element is its own negative. So on the surface this makes sense, notwithstanding the unintuitive enum corner case behaviour
The article is about the complement, not the negative.
I wonder if [[=std::bitmask_type]] also enables compiler warnings that a switch statement is not exhaustive if it does not cover all possible flag combinations.
I thought attributes were reserved for compiler-specific semantics like calling conventions. Here they're just being used as stropping for a language feature with syntactic significance!
It's not an attribute, it's an annotation. Annotations start with [[= .
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p33...