This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
David Brown<david@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.
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |