Question

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?

Answer 1

The standard doesn’t provide volatile member 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 const member functions, in a volatile member function this is 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 via this.

I suspect it would only be worth providing volatile member functions for a class that wraps some bit of memory that might actually be volatile or might not. Then the user can create a volatile or non-volatile object as applicable. If the memory definitely needs to be volatile, then I think you’re better off with non-volatile objects having a volatile data 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 volatile and non-volatile versions of the member functions, containing identical code, one of which will be optimized and the other not.