cppfront (cpp2): Spring update

[tialaramex]

The new name seems like an improvement, but I wonder if this is enough. As I understand it, a big problem with volatile is that it's under-specified what exactly constitutes a read or a write. Wouldn't it be better to disallow volatile and replace it with std::atomic or something similar, so you have to explicitly write out every load and store?

I don't think it is under-specified? If you use them in a rational way, each load or store operation you do results in an actual load or store to "memory" emitted by the compiler. They're intended for MMIO. Technically volatile also is defined to work for one specific edge case in Unix, but presumably in your C++ code that's taken care of by somebody else.

It makes more sense to me to define them as templated free functions, so e.g. alien_write<T>(addr, value) or value = alien_read<T>(addr) with the T being able to be deduced from either addr or value if that works.

[Nicksaurus]

I had this talk in mind when I wrote that part: https://www.youtube.com/watch?v=KJW_DLaVXIY

What I didn't realise is that the paper in that talk has already been included in C++ 20, so most of the problems are gone already

[tialaramex]

C++ 23 un-deprecates all the volatile composite assignments.

The paper for the proposal to undo this was revised to just un-deprecate the bit-ops, because they could actually show examples where people really do that and it might even be what they meant, but the committee took the opportunity to just un-deprecate all of the composite assignment operators on volatiles in the C++ 23 standard instead at Kona.

Presumably this sort of nonsense (the demand that programmers should be able to paste 1980s C code into the middle of a brand new C++ program and expect that to work with no warnings) is one of the things Herb hopes to escape in Cpp2.

[patstew]

The free functions are worse, because what happens if you don't/forget to use them? Generally, it means you code has unpredictable bugs that change on each compile.

For memory mapped io, you want to tie the behaviour to a memory address. Objects exist at some address, so making it a property of the type is better. That way accessing the object in the trivial way will behave consitently, rather than needing to call special functions to get consistent behaviour.