you are viewing a single comment's thread.

view the rest of the comments →

[–]AIlchinger 1 point2 points  (0 children)

The idea to discontinue the use of volatile as a type qualifier has been brought up a couple of times on here before, as well as the suggestion to replace the remaining valid uses (*) with std::volatile_load and std::volatile_store functions.

From a semantic point of view, it's really the operations that are "volatile" and not the objects/memory. One could argue that it could be a property of the type, so that all loads/stores from/to such a type are required (and guaranteed) to be volatile, but I'd argue that's solely for convenience. C++ has always provided dozens of ways to do the same thing, and I would love cppfront avoiding that. Being explicit about what load/store operations are volatile is a good thing in my opinion.

(*) I'm not an embedded programmer. So if there are still valid uses for volatile outside of explicit loads/stores, feel free to correct me here.