C++: const volatile methods

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?

possible duplicate of [C++ - What does volatile represent when applied to a method?](http://stackoverflow.com/questions/5106196/c-what-does-volatile-represent-when-applied-to-a-method) — Oliver Charlesworth, Jan 25 '12 at 17:04

score 3 · Accepted Answer · edited Apr 22 '15 at 12:26

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.

`std::atomic` has `volatile` overloads of most of its member functions. — Mike Seymour, Jan 25 '12 at 17:20
"then I think you're better off with non-volatile objects having a volatile data member" -- exactly -- I actually have a top-level object having volatile member objects having data members. (There's a reason for it that I can't go into here.) — Jason S, Jan 25 '12 at 18:04
@Steve I ended up here from Google because placement new doesn't work with volatile pointers. See: http://ideone.com/FHTVr — Eloff, Sep 15 '12 at 18:04
@Eloff: true. The "normal" way you use placement new to create a volatile object is this: http://ideone.com/LlTqm. In the case in my answer, where you're creating your special object over the top of volatile memory, I think it would be OK to const-cast your pointer to non-volatile provided that your constructor doesn't read or modify the memory (which would be satisfied if the constructor is trivial). To be safe maybe you should overload placement new for the class, provide a `volatile void*` version, and in that do something implementation-dependent instead of calling regular placement new. — Steve Jessop, Sep 17 '12 at 09:09

score 1 · Answer 2 · answered Jan 25 '12 at 17:05

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.

C++: const volatile methods

2 Answers2