I'm having a brain cramp:
struct MyStruct
{
int x;
...
inline int getX1() const { return x; }
inline int getX2() const volatile { return x; }
};
volatile MyStruct myStruct;
I understand that the compiler will let me call myStruct.getX2() and won't let me call myStruct.getX1(), because methods called on volatile structs/classes must have the volatile qualifier on those methods.
Here's my question: If I create such a class, and I publish it for use by other software routines, what are the reasons I would add or not add a volatile qualifier on a method?
Is it because a method tagged volatile tells the compiler not to assume any of its members are not volatile, for optimization purposes, whereas if a method is not tagged volatile, then any members not tagged volatile can be optimized?
The standard doesn't provide
volatilemember functions for any standard classes, so under normal circumstances neither should you.You're right about the implications in the last paragraph - just as with
constmember functions, in avolatilemember functionthisis a pointer-to-volatile. And so whatever your implementation does to implement volatile memory access (disabling various kinds of optimization, for starters), it will do it for any accesses viathis.I suspect it would only be worth providing
volatilemember functions for a class that wraps some bit of memory that might actually be volatile or might not. Then the user can create avolatileor non-volatileobject as applicable. If the memory definitely needs to be volatile, then I think you're better off with non-volatileobjects having avolatiledata member.Now I'm trying to imagine a real use -- a "counter" class that can be created over the top of a magic address that's updated by the hardware or by an interrupt you've written (in which case you could create a volatile instance with placement new), but also has a use-case where it's only ever updated by calls from "normal" code (in which case it can be a non-volatile instance). You'd probably just take the "performance hit" of making the data member volatile in both cases, since it does no other harm. But you could provide
volatileand non-volatileversions of the member functions, containing identical code, one of which will be optimized and the other not.