const Foo* foo_;
gizmo.foo_->bar_ = 42;
...the compiler won't allow it, because it's marked const. Obviously you can get around this by using const_cast to cast away the const-ness, but if you need to be convinced this is a bad idea then there is no help for you. :)
@Pooria: Here: "when reading from a location of memory which is written to by several threads or processes the volatile keyword should be used for that location" This assertion is absolutely false. volatile does nothing for you here other than give you a false sense of security.
@Pooria: I can only hope that your defensive attitude and refusal to answer my questions is an indication that you are offended because you've learned that you were wrong. For what it's worth, I always read everything that everyone has to say. That's how I learn.
@Pooria: In your linked question, the accepted answer deals specifically with memory-mapped hardware. If you had read my post, you will have noted that a) I specifcally say that's what volatile is for, and b) even that has nothing to do with multithreadded programming. It has to do with hardware access.
@Pooria: In your very first sentence.
Alexandrescu's use of volatile is exactly the same. It doesn't do anything to make the memory somehow "thread safe" in any way whatsoever. What it does is it gives the compiler another way to let you know when you may have screwed up. You mark things that you have made truly "thread safe" (through the use of actual synchronization objects, like Mutexes or Semaphores) as being volatile. Then the compiler won't let you use them in a non-volatile context. It throws a compiler error you then have to think about and fix. You could again get around it by casting away the volatile-ness using const_cast, but this is just as Evil as casting away const-ness.
EDIT: I'll try to elaborate a little bit on what I just said.
It can also be used in a similar way that const is used, and this is how Alexandrescu uses it in this article. But make no mistake. volatile doesn't make your code magically thread safe. Used in this specific way, it is simply a tool that can help the compiler tell you where you might have messed up. It is still up to you to fix your mistakes, and volatile plays no role in fixing those mistakes.
My advice to you is to completely abandon volatile as a tool in writing multithreadded applications (edit:) until you really know what you're doing and why. It has some benefit but not in the way that most people think, and if you use it incorrectly, you could write dangerously unsafe applications.
Suppose you have a class that has a pointer to something that cannot change. You might naturally make the pointer const:
What does const really do for you here? It doesn't do anything to the memory. It's not like the write-protect tab on an old floppy disc. The memory itself it still writable. You just can't write to it through the foo_ pointer. So const is really just a way to give the compiler another way to let you know when you might be messing up. If you were to write this code:
What volatile is used for is interfacing with memory-mapped hardware, signal handlers and the setjmp machine code instruction.
What you know is false. Volatile is not used to synchronize memory access between threads, apply any kind of memory fences, or anything of the sort. Operations on volatile memory are not atomic, and they are not guaranteed to be in any particular order. volatile is one of the most misunderstood facilities in the entire language. "Volatile is almost useless for multi-threadded programming."