4 ms·

1. No, that's wrong. Incrementing a volatile isn't undefined. The problem is that some people are using volatile when they actually want atomic variables, so th

1. No, that's wrong. Incrementing a volatile isn't undefined. The problem is that some people are using volatile when they actually want atomic variables, so the behavior of the program becomes undefined when you have two threads incrementing the same volatile variable at the same time. The compiler might or might not compile volatile_variable++ into an atomic operation, but some people wrote code under the misunderstanding of the language that it always would. 2. Sure. While it's true that using certain features of the language technically requires parts of the standard library, those parts are very few and very simple. What is there? std::move(), std::pair and std::tuple, <typeinfo>, and perhaps a couple other things?

jcelerier 4y ago
std::move is just syntax sugar over static_cast<T&&>(t) ; the language feature that needs library support afaik are: - Overloading some of the "new" operators (need #include <new>) - <initializer_list> - typeid which needs <typeinfo> as you said I don't see which parts of the language need pair and tuple at all?
- deadbeeves 4y ago
  I was mistaken. I thought you needed std::tuple for structured binding, but it seems the language can also destructure other types.
  - jcelerier 4y ago
    it's not that you need it, it's that when destructuring, std::tuple_size / std::tuple_element are implicitly checked to see how destructuring can be made to work if you have a type with some custom destructuring. (example: https://gcc.godbolt.org/z/5jq61oox7 https://gcc.godbolt.org/z/5jq61oox7) If they are not available or just not overloaded (e.g. when destructuring some basic struct) it just falls back to the destructuring one expects. So you need <tuple> for the specific case of implementing custom destructuring, that is one more case to add to the list :)
    - quest88 4y ago
      This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness.
      - deadbeeves 4y ago
        You're being overdramatic. You don't need to be a language lawyer to use C++ correctly and effectively.
      - jcelerier 4y ago
        Which language do you use?
      - arinlen 4y ago
        > This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness. You've tried to force your personal misconceptions as some kind of gotchas that justify you irrational dislike for a programming language, and once each and every misconception you had was dispelled and debunked, your reaction was to double-down on your irrational belief. This does not flag failures in a language.
        Dylan16807 4y ago
        ? That's their only comment on the entire page.
tialaramex 4y ago
> No, that's wrong. Incrementing a volatile isn't undefined. The problem is that some people are using volatile when they actually want atomic variables, so the behavior of the program becomes undefined when you have two threads incrementing the same volatile variable at the same time. The compiler might or might not compile volatile_variable++ into an atomic operation, but some people wrote code under the misunderstanding of the language that it always would. What you're describing is a different long standing problem. The deprecation of compound volatile operations is because as volatile operations they were nonsense. A volatile operation is a single non-tearing fetch or store, but compound operations by their nature are both a fetch and a store. By obliging users of volatiles to be explicit with the separate fetch and store, the intent was to highlight that this is not a single operation. Abuse of volatile to mean "atomic" is so widespread it's how MSVC actually works by default on x86. Access to volatiles with MSVC /volatile:ms - which is default for x86 targets - means Aquire-Release atomic semantics. Deprecating the compound ops doesn't change that in either direction, it's a bad idea, people, especially Windows developers, will expect it to work, Microsoft will enable it on x86 (but by default not on ARM).

jcelerier 4y ago

std::move is just syntax sugar over static_cast<T&&>(t) ; the language feature that needs library support afaik are: - Overloading some of the "new" operators (need #include <new>) - <initializer_list> - typeid which needs <typeinfo> as you said I don't see which parts of the language need pair and tuple at all?

deadbeeves 4y ago
I was mistaken. I thought you needed std::tuple for structured binding, but it seems the language can also destructure other types.
- jcelerier 4y ago
  it's not that you need it, it's that when destructuring, std::tuple_size / std::tuple_element are implicitly checked to see how destructuring can be made to work if you have a type with some custom destructuring. (example: https://gcc.godbolt.org/z/5jq61oox7 https://gcc.godbolt.org/z/5jq61oox7) If they are not available or just not overloaded (e.g. when destructuring some basic struct) it just falls back to the destructuring one expects. So you need <tuple> for the specific case of implementing custom destructuring, that is one more case to add to the list :)
  - quest88 4y ago
    This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness.
    - deadbeeves 4y ago
      You're being overdramatic. You don't need to be a language lawyer to use C++ correctly and effectively.
    - jcelerier 4y ago
      Which language do you use?
    - arinlen 4y ago
      > This whole thread is why c++ is..bad. It just leaves me with a sense of hopelessness. You've tried to force your personal misconceptions as some kind of gotchas that justify you irrational dislike for a programming language, and once each and every misconception you had was dispelled and debunked, your reaction was to double-down on your irrational belief. This does not flag failures in a language.
      - Dylan16807 4y ago
        ? That's their only comment on the entire page.

tialaramex 4y ago

> No, that's wrong. Incrementing a volatile isn't undefined. The problem is that some people are using volatile when they actually want atomic variables, so the behavior of the program becomes undefined when you have two threads incrementing the same volatile variable at the same time. The compiler might or might not compile volatile_variable++ into an atomic operation, but some people wrote code under the misunderstanding of the language that it always would. What you're describing is a different long standing problem. The deprecation of compound volatile operations is because as volatile operations they were nonsense. A volatile operation is a single non-tearing fetch or store, but compound operations by their nature are both a fetch and a store. By obliging users of volatiles to be explicit with the separate fetch and store, the intent was to highlight that this is not a single operation. Abuse of volatile to mean "atomic" is so widespread it's how MSVC actually works by default on x86. Access to volatiles with MSVC /volatile:ms - which is default for x86 targets - means Aquire-Release atomic semantics. Deprecating the compound ops doesn't change that in either direction, it's a bad idea, people, especially Windows developers, will expect it to work, Microsoft will enable it on x86 (but by default not on ARM).