Skip to content

Piero Bosio Social Web Site Personale Logo Fediverso

Social Forum federato con il resto del mondo. Non contano le istanze, contano le persone

Hello Mastodon!

Uncategorized
14 10 1
  • 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 type

    Wait 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 type

    Wait 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 type

    Wait 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.

  • aeva@mastodon.gamedev.placeundefined aeva@mastodon.gamedev.place shared this topic
  • 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 Strong start with Mastodon! Keep it going! 😄

  • 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 This hits surprisingly close to home as I try to create a compatibility layer for decompilers: since they work with partial information by definition they regularly introduce stuff that has a name but has no/0 length (the rest is an exercise for the user). Now how do you explain the *other* decompiler what that zero-length thing means? :)
  • 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
    I disagree with details regarding the negative width signed integer types.
    The limits of the representable values of a two's complement integer n bits wide are -(2^(n-1)) and 2^(n-1)-1, so a signed integer -1 bits wide has limits on representable values of -0.25 and -0.75, and such a type can only represent one half of a distinct value.
    I agree that such a data type seems to be of rather dubious utility. But just imagine how many of them you can store, before you run out of memory!

  • @zygoloid
    I disagree with details regarding the negative width signed integer types.
    The limits of the representable values of a two's complement integer n bits wide are -(2^(n-1)) and 2^(n-1)-1, so a signed integer -1 bits wide has limits on representable values of -0.25 and -0.75, and such a type can only represent one half of a distinct value.
    I agree that such a data type seems to be of rather dubious utility. But just imagine how many of them you can store, before you run out of memory!

    @zygoloid
    Suppose you have 1 KiB of memory. You ordinarily can use it to store no more than 1024 values of a std::int8_t.
    Supposing we have a new data type, std::intnegative8_t, we can e.g. store 1024 of those in our memory, along with 2048 values of type std::int8_t. We have doubled how many signed bytes we can store in a fixed size block of memory, at the relatively minor cost of allocating a few additional data items as overhead.

  • oblomov@sociale.networkundefined oblomov@sociale.network shared this topic

Gli ultimi otto messaggi ricevuti dalla Federazione
Post suggeriti