4 ms·
So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool The "pre/post increment of volatiles is deprecated" sounds like a huge p
by raverbashing 4y ago
So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool
The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)
- mgaunard 4y agowell to begin with if you're using volatile, you're probbaly doing something wrong already. The valid use cases for it are ridiculously few.
- munch117 4y agoBut if you're using volatile correctly, then there's nothing wrong with ++*v. I was wondering about that slide that says the meaning is unclear, I don't see what's unclear about it. What particular assembly instructions it translates into is irrelevant. It's not like ++ is guaranteed atomic or anything.
- RicardoLuis0 4y agoit's not guaranteed atomic, and if you ARE using volatiles, "maybe" doesn't really cut it, so now you need to do `++*v` the proper way (ex. `lock cmpxchg` / `__atomic_compare_exchange`), or explicitly write it out the long way (`*v = *v + 1`) and risk the small chance of the value changing under you between read/write
- mgaunard 4y agousing volatile correctly usually means you're manipulating write-combining memory. Write-combining memory has weak memory ordering where all writes are delayed so anything doing both reads and writes is most likely going to bite you in the neck.
- munch117 4y agoIf you're accessing any kind of I/O register or special memory, obviously you need to know the rules of engagement for the particular kind. If you don't, then you're just going to be making the same mistake in a less obvious guise. Like writing *v=*v+1 instead of *v++.
- scatters 4y agoThat's been undeprecated in C++23. It's mildly embarrassing, but it shows the process works.
- fatneckbeardz 4y agodon't you mean ++C23
- cpeterso 4y agoAre all of C++20’s volatile deprecations un-deprecated in C++23? This doc from 2020 lists all: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2139r1.html#3.5 https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p21... But this proposal from 2021 suggests only undeprecating bitwise compound operations: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2327r1.pdf https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...