@EVOEx: it's not normally a good idea to make anything other than primitives volatile. A "volatile std::queue" won't do what you think it does, because the queue variable will be volatile, but the majority of its data will be on the heap, and that will not be volatile. You could, I suppose, say "std::queue<volatile int>", but if you're doing that you really need to re-think your design.
Everyone seems to know this more or less but I thought I'd state it again: volatile is just meant to tell the compiler that the value of this variable could change without warning, outside of the normal program flow control. Hence, don't cache read-values for the variable because it could have changed. There are many situations in which this could arise, and certainly multithreaded flags are a common example.
You do not need to say volatile if you're for example spinning on a variable (while(var)), but could change the variable in the loop. The compiler will notice this with definition-use chains and kill the value used by the while loop, and it won't do the wrong thing with e.g.
Compiler optimizations are supposed to preserve the functionality of the program. But the compiler can only do this properly if it has full information, and one of the assumptions it makes is it can see changes to a variable within a function or whatever. Normally, this is perfectly fine. It's only when you're doing something outside of normal flow control that you may need to use volatile -- here "normal flow control" includes loops, conditionals, exceptions, function calls, etc. (Probably doesn't include longjmp though, because longjmp sucks.)Code:while(flag) { if(std::rand() % 100) flag = false; }
Cheers, dwk.
