C++: const volatile methods

1.8k Views Asked by At

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?

2

There are 2 best solutions below

4
On BEST ANSWER

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.

0
On

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?

Yes.

In a volatile function, the *this object becomes volatile which in turn means every non-static member of the class becomes volatile, just like in a const function, the *this object becomes const which in turn means every non-static member of the class becomes const.

Having said that the compile refrains from aggressively optimizing the code involving members in a volatile function.