8 ms·

C++’s memory model has not changed much (if at all) since C++11. The Rust documentation specifically refers you to the C++20 standard, because they had to pick

C++’s memory model has not changed much (if at all) since C++11. The Rust documentation specifically refers you to the C++20 standard, because they had to pick some version, but the C++20 memory model is (as far as I know) the same memory model introduced with the C/C++11 standards.

pjmlp 5y ago
Kind of, volatile meaning changed, but they are looking into it for C++23 as the embedded community is not happy with the outcome.
- tialaramex 5y ago
  But, volatile isn't actually part of the memory model (except arguably in MSVC). And all that was changed was to deprecate things that are a bad idea. They don't mean anything different, they aren't hard errors, they're just deprecated. The embedded community in this context is people who were able to: #include <embedded_vendor/mmio_stuff.h> ... a file full of dodgy C pre-processor macros into their C++ project and are unhappy that J. F. Bastien's volatile deprecation means now their compiler points out what a terrible idea some of those macros actually are. Having the compiler shut up and silently allow this might make them feel better, but the situation they're in isn't actually improved by such a reversion at all. Removing the batteries and disabling the smoke alarm does mean you get a peaceful night's sleep, but sometimes you don't wake up after that peaceful night's sleep because meanwhile your home burned down and there was no alarm. The claim made in the proposal paper is that every C++ programmer who is including such macros definitely ensures by construction that their use of the macros is actually safe. You've probably read a bunch of real world C++ code written by people who are very confident in their ability to write correct programs, how do you feel about the likelihood that all these programs are in fact correct by construction despite using the unsafe macros? It seems that in later revisions of the proposal, they considerably reduced the scope of the un-deprecation, realising that even if you earnestly believe (interrupt_register |= ENABLE_IRQC) isn't a footgun, it's much harder to rationalise (clock_rate /= 3) and either way nobody wanted half the random places C++ allowed you to write "volatile" anyway, so deprecating those isn't actually a problem and "reverting" the deprecation just highlights yet another mysterious black box in C++ with no clear purpose.
  - pjmlp 5y ago
    Yep, I am with you on that, it is that kind of subculture that spoils the fun of using C++, and no matter what the community does to improve the language, such kind of source bases will always be around in some companies.

pjmlp 5y ago

Kind of, volatile meaning changed, but they are looking into it for C++23 as the embedded community is not happy with the outcome.

tialaramex 5y ago
But, volatile isn't actually part of the memory model (except arguably in MSVC). And all that was changed was to deprecate things that are a bad idea. They don't mean anything different, they aren't hard errors, they're just deprecated. The embedded community in this context is people who were able to: #include <embedded_vendor/mmio_stuff.h> ... a file full of dodgy C pre-processor macros into their C++ project and are unhappy that J. F. Bastien's volatile deprecation means now their compiler points out what a terrible idea some of those macros actually are. Having the compiler shut up and silently allow this might make them feel better, but the situation they're in isn't actually improved by such a reversion at all. Removing the batteries and disabling the smoke alarm does mean you get a peaceful night's sleep, but sometimes you don't wake up after that peaceful night's sleep because meanwhile your home burned down and there was no alarm. The claim made in the proposal paper is that every C++ programmer who is including such macros definitely ensures by construction that their use of the macros is actually safe. You've probably read a bunch of real world C++ code written by people who are very confident in their ability to write correct programs, how do you feel about the likelihood that all these programs are in fact correct by construction despite using the unsafe macros? It seems that in later revisions of the proposal, they considerably reduced the scope of the un-deprecation, realising that even if you earnestly believe (interrupt_register |= ENABLE_IRQC) isn't a footgun, it's much harder to rationalise (clock_rate /= 3) and either way nobody wanted half the random places C++ allowed you to write "volatile" anyway, so deprecating those isn't actually a problem and "reverting" the deprecation just highlights yet another mysterious black box in C++ with no clear purpose.
- pjmlp 5y ago
  Yep, I am with you on that, it is that kind of subculture that spoils the fun of using C++, and no matter what the community does to improve the language, such kind of source bases will always be around in some companies.