26

What is the purpose of a volatile member function in C++?

AshleysBrain
  • 22,335
  • 15
  • 88
  • 124
user293666
  • 281
  • 3
  • 3
  • This just asked: http://stackoverflow.com/questions/2444695/volatile-vs-mutable-in-c – wheaties Mar 15 '10 at 02:39
  • Dup: http://stackoverflow.com/questions/246127/why-is-volatile-needed-in-c (and probably lots more) – Adam Rosenfield Mar 15 '10 at 02:49
  • @Adam, Either we close this when interpreted as "what function does volatile have in C++?", or we leave it open when interpreted as "what purpose do volatile (member-) functions have in C++?". Probably only the question owner knows... (look into the edit-log to see the original form of the question. quite hilarious). – Johannes Schaub - litb Mar 15 '10 at 02:57

2 Answers2

26

To answer the question about what it means to have a 'volatile member function' (which may or may not be what was originally intended by the person who posted the question), marking a member function as const or volatile (or a combined const volatile) applies those qualifiers to the this pointer used in the function. As stated by the standard (9.2.1 "The this pointer"):

The type of this in a member function of a class X is X*. If the member function is declared const, the type of this is const X*, if the member function is declared volatile, the type of this is volatile X*, and if the member function is declared const volatile, the type of this is const volatile X*.

So by marking the member function as volatile you'd be making any access to the non-static data members of the object within that member function as volatile.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • 9
    So practically speaking, if `obj` is `volatile Object * obj`, then you can't invoke a member function that is _not_ marked `volatile`. – bobobobo Aug 16 '13 at 14:59
8

EDIT:

This answer was posted when the question was about the volatile keyword. Question seems to have been changed by a third party.

ORIGINAL:

Volatile informs the compiler that it should not assume that the value it just put in the variable marked as volatile will be there next time it uses it... that it must check the current value before using it again.

One example is if the variable represents a memory location that might be changed by another process.

Here's an example (been ages since I did C++ so please forgive any minor syntax issues):

volatile int x;

int DoSomething()
{
    x = 1;

    DoSomeOtherStuff();

    return x+1; // Don't just return 2 because we stored a 1 in x.  
                // Check to get its current value
}
Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • 2
    This is correct. It is often used in embedded and realtime applications. – penguin4hire Mar 15 '10 at 02:37
  • 5
    @jasonline: it tells the compiler that it must not change the number or order of reads and writes, and it must not move any reads or writes across sequence points. It doesn't exactly tell it "not to perform any optimizations". For example, loops which modify volatiles can still be unrolled, and code accessing volatiles can be moved across non-volatile accesses. I guess even speculative execution would be OK provided that you had hardware transactional memory and no magic I/O addresses. – Steve Jessop Mar 15 '10 at 03:00
  • @Steve: Thanks for your clarification. I actually quoted it from these: http://msdn.microsoft.com/en-us/library/12a04hfd(VS.80).aspx and http://en.wikipedia.org/wiki/Volatile_variable. – jasonline Mar 15 '10 at 06:01
  • The two are probably close enough for jazz and government work, though. It's a question of carefully defining what it means to perform the optimisation "on it (the volatile object)", and making it match the list of optimizations actually banned ;-) – Steve Jessop Mar 15 '10 at 06:01
  • @Steve: I see. Actually banned? Care to explain on this? – jasonline Mar 15 '10 at 06:12
  • I mean that some optimizations which could be performed on code with non-volatile objects are forbidden by the standard if the object is volatile. So, if you define an optimization to be "on" an object if and only if it is one of those optimizations forbidden by the standard when that object is volatile, then your original statement is true. The compiler can perform optimizations "near it", "around it", and "either side of it", but not "on it". – Steve Jessop Mar 15 '10 at 15:07
  • As for the history, it appears the question was briefly edited into a duplicate question about the 'volatile' keyword by a third party; originally, it was a question about 'volatile' functions. This answer must have been posted when this question was in that erroneous state. It was then edited back into a question about 'volatile' functions, as per the original asker's intent. – Theodore Murdock Feb 09 '16 at 19:21