Hacker News Reader

Comment by raverbashing | Hacker News Reader

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)

View on HN

That's been undeprecated in C++23. It's mildly embarrassing, but it shows the process works.

don't you mean ++C23

Are 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/p21...

But this proposal from 2021 suggests only undeprecating bitwise compound operations:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p23...

Sorry, you're right, my bad. People are actually writing compound arithmetic assignment ops on volatiles, huh.

You got my hopes up about un-deprecation :) but I was glad to at least learn about the proposals

well to begin with if you're using volatile, you're probbaly doing something wrong already.

The valid use cases for it are ridiculously few.

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

it'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

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

If 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++.

Reply on news.ycombinator.com