Hello Mastodon!
-
Hello Mastodon!
Since this is my first post, I thought I'd share some incredibly niche C++ trivia / pedantry:
For an enum whose enumerators all have the value 0, C++ asks us to imagine a hypothetical integer type with minimal width that can represent 0 (https://eel.is/c++draft/dcl.enum#8.sentence-2). This means we must consider the case where the width is 0. For an unsigned integer type, this gives a range of representable values of [0, 0], and that's the type we pick. But before we can determine that that's minimal, we must also consider a signed integer type with a width of 0, for which we get a range of representable values of [-½, -½]! (https://eel.is/c++draft/basic.fundamental#1.sentence-5) Conveniently that range does not include 0, so we discover that we must use an unsigned integer type to determine the range of values of the enumeration. (We also rule out an unsigned integer type of negative width as that would have a range of values 0 to -½ (inclusive) or smaller, which I think we can reasonably conclude is an empty range despite the parenthetical.)
In any case: if you ever wondered whether a zero-bit signed integer type in C++ can represent only the value 0 or only the value -1, now you know: no, it can represent only the value -½. Truly a marvelous compromise.
Follow me for more brilliant insights like this one :)
-
Hello Mastodon!
Since this is my first post, I thought I'd share some incredibly niche C++ trivia / pedantry:
For an enum whose enumerators all have the value 0, C++ asks us to imagine a hypothetical integer type with minimal width that can represent 0 (https://eel.is/c++draft/dcl.enum#8.sentence-2). This means we must consider the case where the width is 0. For an unsigned integer type, this gives a range of representable values of [0, 0], and that's the type we pick. But before we can determine that that's minimal, we must also consider a signed integer type with a width of 0, for which we get a range of representable values of [-½, -½]! (https://eel.is/c++draft/basic.fundamental#1.sentence-5) Conveniently that range does not include 0, so we discover that we must use an unsigned integer type to determine the range of values of the enumeration. (We also rule out an unsigned integer type of negative width as that would have a range of values 0 to -½ (inclusive) or smaller, which I think we can reasonably conclude is an empty range despite the parenthetical.)
In any case: if you ever wondered whether a zero-bit signed integer type in C++ can represent only the value 0 or only the value -1, now you know: no, it can represent only the value -½. Truly a marvelous compromise.
Follow me for more brilliant insights like this one :)
Elvis has entered the building
-
Elvis has entered the building
-
Hello Mastodon!
Since this is my first post, I thought I'd share some incredibly niche C++ trivia / pedantry:
For an enum whose enumerators all have the value 0, C++ asks us to imagine a hypothetical integer type with minimal width that can represent 0 (https://eel.is/c++draft/dcl.enum#8.sentence-2). This means we must consider the case where the width is 0. For an unsigned integer type, this gives a range of representable values of [0, 0], and that's the type we pick. But before we can determine that that's minimal, we must also consider a signed integer type with a width of 0, for which we get a range of representable values of [-½, -½]! (https://eel.is/c++draft/basic.fundamental#1.sentence-5) Conveniently that range does not include 0, so we discover that we must use an unsigned integer type to determine the range of values of the enumeration. (We also rule out an unsigned integer type of negative width as that would have a range of values 0 to -½ (inclusive) or smaller, which I think we can reasonably conclude is an empty range despite the parenthetical.)
In any case: if you ever wondered whether a zero-bit signed integer type in C++ can represent only the value 0 or only the value -1, now you know: no, it can represent only the value -½. Truly a marvelous compromise.
Follow me for more brilliant insights like this one :)
@zygoloid
> But before we can determine that that's minimal, we must also consider a signed integer typeWait a minute; why must we consider such a signed type? Why can't the hypothetical zero-width unsigned type exist, while at the same time a corresponding signed type does _not_ exist?
-
@zygoloid
> But before we can determine that that's minimal, we must also consider a signed integer typeWait a minute; why must we consider such a signed type? Why can't the hypothetical zero-width unsigned type exist, while at the same time a corresponding signed type does _not_ exist?
@zygoloid
i guess it would be because the unsigned type's object/value representation would be defined in terms of the corresponding signed type (https://eel.is/c++draft/basic.fundamental#3)...?Except that you could argue that a zero-width type doesn't actually _need_ an object/value representation (but on second thought, i guess p3 forces the signed type to exist whether we "need" it or not).
And it's still conspicuous that the first sentence in p2 does not end with, "... and vice-versa".
-
@zygoloid
> But before we can determine that that's minimal, we must also consider a signed integer typeWait a minute; why must we consider such a signed type? Why can't the hypothetical zero-width unsigned type exist, while at the same time a corresponding signed type does _not_ exist?
@JamesWidman @zygoloid I don't think he's saying the signed integer type doesn't exist, just that it cannot represent 0.
-
@JamesWidman @zygoloid I don't think he's saying the signed integer type doesn't exist, just that it cannot represent 0.
@lenary @zygoloid i agree in that i _also_ don't think he's saying the signed integer type doesn't exist. (:
the question i was trying to ask was something like: "if an implementation reaches [dcl.enum] p8.sentence-2 for the described input, does the working paper require it to reason about a hypothetical signed type just because it started reasoning about its would-be corresponding hypothetical unsigned type?"
...and at first i suspected the answer is "no", but now i'm not sure.
-
@zygoloid
i guess it would be because the unsigned type's object/value representation would be defined in terms of the corresponding signed type (https://eel.is/c++draft/basic.fundamental#3)...?Except that you could argue that a zero-width type doesn't actually _need_ an object/value representation (but on second thought, i guess p3 forces the signed type to exist whether we "need" it or not).
And it's still conspicuous that the first sentence in p2 does not end with, "... and vice-versa".
@zygoloid btw it's good to see you again!
-
Hello Mastodon!
Since this is my first post, I thought I'd share some incredibly niche C++ trivia / pedantry:
For an enum whose enumerators all have the value 0, C++ asks us to imagine a hypothetical integer type with minimal width that can represent 0 (https://eel.is/c++draft/dcl.enum#8.sentence-2). This means we must consider the case where the width is 0. For an unsigned integer type, this gives a range of representable values of [0, 0], and that's the type we pick. But before we can determine that that's minimal, we must also consider a signed integer type with a width of 0, for which we get a range of representable values of [-½, -½]! (https://eel.is/c++draft/basic.fundamental#1.sentence-5) Conveniently that range does not include 0, so we discover that we must use an unsigned integer type to determine the range of values of the enumeration. (We also rule out an unsigned integer type of negative width as that would have a range of values 0 to -½ (inclusive) or smaller, which I think we can reasonably conclude is an empty range despite the parenthetical.)
In any case: if you ever wondered whether a zero-bit signed integer type in C++ can represent only the value 0 or only the value -1, now you know: no, it can represent only the value -½. Truly a marvelous compromise.
Follow me for more brilliant insights like this one :)
@zygoloid@hachyderm.io "Integer"
looks inside
fractional value -
Hello Mastodon!
Since this is my first post, I thought I'd share some incredibly niche C++ trivia / pedantry:
For an enum whose enumerators all have the value 0, C++ asks us to imagine a hypothetical integer type with minimal width that can represent 0 (https://eel.is/c++draft/dcl.enum#8.sentence-2). This means we must consider the case where the width is 0. For an unsigned integer type, this gives a range of representable values of [0, 0], and that's the type we pick. But before we can determine that that's minimal, we must also consider a signed integer type with a width of 0, for which we get a range of representable values of [-½, -½]! (https://eel.is/c++draft/basic.fundamental#1.sentence-5) Conveniently that range does not include 0, so we discover that we must use an unsigned integer type to determine the range of values of the enumeration. (We also rule out an unsigned integer type of negative width as that would have a range of values 0 to -½ (inclusive) or smaller, which I think we can reasonably conclude is an empty range despite the parenthetical.)
In any case: if you ever wondered whether a zero-bit signed integer type in C++ can represent only the value 0 or only the value -1, now you know: no, it can represent only the value -½. Truly a marvelous compromise.
Follow me for more brilliant insights like this one :)
@zygoloid most people most of the time don't understand the enum rules in c, and even less so in c++.
Just the fact that assigning integer values to enum values is commonplace should tell us that!
This is pretty spectacular tho, I did not know about this.
-
undefined aeva@mastodon.gamedev.place shared this topic