On 25/09/11 16:16, Andreas Schwab wrote:
David Brown<da...@westcontrol.com> writes:
There is a big difference between defining an object as "const", and
merely declaring it as const or accessing it as const. When you access it
as const, you are saying "/I/ won't change the object with this access".
When you declare an object as const (such as an extern object), you are
saying "/I/ won't change this object". When you /define/ an object as
const, as you do with a "static const", you are saying "this object is
constant. It will never change value - you (the toolchain) can safely
place it in read-only memory that cannot ever change value".
You are interpreting too much into const here. The C standard says in
footnote 112: "The implementation may place a const object that is not
volatile in a read-only region of storage." Note the use of "not
volatile". But in any case this is not part of the C standard: it's
only a footnote.
I stand corrected on that point - thanks.
And then you make it volatile, telling the compiler "this object might
change unexpectedly, or use values written to it unexpectedly".
If someone could explain to me how this could have real-world usage, I
think it would be easier for me (and others) to be sure of what it really
means.
It's an object that is never written to, but may change unexpectedly.
Again, I can see that "volatile const" is useful for declaring external
objects (or accesses to objects), but not when the address of the object
is allocated by the toolchain (as is the case here with a "static const
volatile".
The only scenario I have heard where this might be useful is for
debugging - making what is normally a "static const" volatile so that
it's value can be changed with a debugger. Personally, I think that in
such cases you would be better removing the "const" when you add the
"volatile".
