3 ms·

I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "con

I wonder if you're fine with const, constexpr and volatile also being things. I mean, "const" really doesn't mean what one would naively think (that's what "constexpr" is actually for) and the semantics of "volatile" are also widely misunderstood.

tialaramex 7mo ago
Nope, not only is C++ const not a constant, C++ constexpr isn't a constant either, and C++ constinit isn't a constant, C++ consteval is closest, but it's only available for functions. const int a = 10; // Just an immutable variable named a constexpr int b = 20; // Still an immutable variable named b static constinit int c = 30; // Now it isn't even immutable For functions const says this function promises it doesn't change things, constexpr says this function is shiny and modern and has no other real meaning (hence "constexpr all the things" memes, you might as well) but consteval does mean that we're promising this must always be evaluated at compile time, so the evaluation is frozen by runtime, however only a function can have this label. Volatile is a mess because what you actually want are the volatile intrinsics, indeed you might want more (or fewer) depending on the target. If your target can do single bit hardware writes it'd be nice to provide an intrinsic for that, rather than hoping you can write in code REG |= 0x40 and have that write a single bit... which on platforms which do not have this single bit write feature that's going to compile to an unsynchronized read-modify-write which may cause problems. However instead of having intrinsics C's volatile was hacked into the type system instead and C++ tries to keep that.
- functional_dev 7mo ago
  spot on... that difference between evaluation and storage is exactly why C++ is so hard to keep in my head I thought constexpr was a hard physical constant, but in reality it's a weird hybrid this visualisation helped me to wrap my head around it - https://vectree.io/c/c-constness-and-evaluation-qualifiers https://vectree.io/c/c-constness-and-evaluation-qualifiers
- Joker_vD 7mo ago
  groans See, and that's why I'm personally fine with [[indeterminate]], etc: all of this is already a finely-splitted hairy mess and I'd rather not see even more keywords introduced if we can just use attributes instead. And yeah, it would probably be nice to also have some sane intrinsics to provide memory_order_consume semantics... but what can you do.
  - ozgrakkurt 7mo ago
    Const, constexpr etc. Are mandatory to understand at this point. That situation doesn’t justify adding more things imo
  - jcalvinowens 7mo ago
    Consume is dead. Long live acquire! But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.
    - Joker_vD 7mo ago
      If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like ldr x8, [x8] # load a pointer from memory ldr x1, 16[x8] # load a field through that pointer or turning the second load into "ldar" — there is quite a visible data dependency between two registers. But compilers usually puts a barrier there anyway.
      - jcalvinowens 7mo ago
        I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.
        Joker_vD 7mo ago

tialaramex 7mo ago

Nope, not only is C++ const not a constant, C++ constexpr isn't a constant either, and C++ constinit isn't a constant, C++ consteval is closest, but it's only available for functions. const int a = 10; // Just an immutable variable named a constexpr int b = 20; // Still an immutable variable named b static constinit int c = 30; // Now it isn't even immutable For functions const says this function promises it doesn't change things, constexpr says this function is shiny and modern and has no other real meaning (hence "constexpr all the things" memes, you might as well) but consteval does mean that we're promising this must always be evaluated at compile time, so the evaluation is frozen by runtime, however only a function can have this label. Volatile is a mess because what you actually want are the volatile intrinsics, indeed you might want more (or fewer) depending on the target. If your target can do single bit hardware writes it'd be nice to provide an intrinsic for that, rather than hoping you can write in code REG |= 0x40 and have that write a single bit... which on platforms which do not have this single bit write feature that's going to compile to an unsynchronized read-modify-write which may cause problems. However instead of having intrinsics C's volatile was hacked into the type system instead and C++ tries to keep that.

functional_dev 7mo ago
spot on... that difference between evaluation and storage is exactly why C++ is so hard to keep in my head I thought constexpr was a hard physical constant, but in reality it's a weird hybrid this visualisation helped me to wrap my head around it - https://vectree.io/c/c-constness-and-evaluation-qualifiers https://vectree.io/c/c-constness-and-evaluation-qualifiers
Joker_vD 7mo ago
groans See, and that's why I'm personally fine with [[indeterminate]], etc: all of this is already a finely-splitted hairy mess and I'd rather not see even more keywords introduced if we can just use attributes instead. And yeah, it would probably be nice to also have some sane intrinsics to provide memory_order_consume semantics... but what can you do.
- ozgrakkurt 7mo ago
  Const, constexpr etc. Are mandatory to understand at this point. That situation doesn’t justify adding more things imo
- jcalvinowens 7mo ago
  Consume is dead. Long live acquire! But seriously, it is interesting how C++ is completely abandoning the concept. My handwavy understanding is that on some more specialized hardware acquire is substantially more expensive than consume.
  - Joker_vD 7mo ago
    If by "more specialized hardware" you mean "everything that is not x86". Its main intended use is (was?) for chained loads and rcu_dereference(), where hardware does not require an explicit memory fence between loads like ldr x8, [x8] # load a pointer from memory ldr x1, 16[x8] # load a field through that pointer or turning the second load into "ldar" — there is quite a visible data dependency between two registers. But compilers usually puts a barrier there anyway.
    - jcalvinowens 7mo ago
      I'm not saying it doesn't matter. It just clearly doesn't matter enough on modern common non-tso CPUs enough to motivate anybody to add the compiler support. The history of the whole thing is very interesting.
      - Joker_vD 7mo ago