![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
|
Anyone know of other languages that support this? Wouter Lievens 10:47, 28 Apr 2005 (UTC)
struct C {
int i;
int (* Get)(const struct C *self); /* Note the const tag */
void (* Set)(struct C *self, int j);
};
/* The method implementations must of course still be wired (by a constructor) */
int C_Get(const struct C *self) { return i; } /* Note the const tag */
void C_Set(struct C *self, int j) { self->i = j; }
void
Foo(struct C *nonConstC, const struct C *constC) {
int y = nonConstC->Get(nonConstC); /* Ok */
int x = constC->Get(constC); /* Ok: Get() is const */
nonConstC->Set(nonConstC, 10); /* Ok: nonConstC is modifiable */
constC->Set(constC, 10); /* Error: Set() might modify constC! */
}
I barely know the semantic of const, so I may be wrong but isn't this article talking about the same thing as immutable object? Of course, there is a difference but I don't think it is much to warrant two separate articles. So I am adding merge tag. Feel free to correct me if necessary. -- Taku 09:55, Jun 23, 2005 (UTC)
Both articles are way more than stubs, and their topics really don't overlap much. I've been bold and removed the merge notices. -- Quuxplusone 22:15, 21 July 2005 (UTC)
I've been building hardware and writing plain ANSI C for some time. I suspect "const" and "volatile" would be easier to understand if we approached it from a hardware point of view. (On the other hand, perhaps it just *seems* simpler that way because I'm more familiar with hardware than with C#).
Let me hash out a rough draft here:
Modern CPUs use a von Neumann architecture, composed of a central processing unit, some random access memory, and the bus between them.
Each word of RAM only responds to one particular address, and ignores all other addresses.
Almost always there are other devices on the bus -- each one responds to its own particular address.
ROM also watches the bus, responding only to *reads* to a particular address, ignoring all writes.
Many microprocessors have a reasonable amount of ROM, but only a few precious bytes of RAM.
When a program is intended to go into a ROM, the programmer marks some data structures as "const". This tells the the compiler that it is permissible to put that data into the ROM.
Some subroutines modify data structures. Since it never makes sense to try to modify data values in ROM, good compilers will refuse to compile code that has this problem.
Other peripherals also watch the bus, waiting for their particular address to be selected, and either given a command, or a request for data. Now, if the program (as written) writes the value '\f' to normal RAM twice, it doesn't matter if the compiler re-arranges things so that it only writes it once (or, for that matter, 5 times). However, let me assure you that people will notice the difference between a formfeed character being sent to the printer once, twice, or 5 times.
Some serial ports buffer the data from the line, and have a special address for reading the next byte (which removes that byte from the buffer). If a program (as written) reads from some RAM address 1000 times (without any intervening write), it doesn't matter if the compiler re-arranges things so that it only reads that value once (and caches it in a register for the next read) (or, for that matter, reads it 2000 times). However, let me assure you that people will notice the difference between a program that responds to the real activity on a keyboard, vs. a program that reads only the first keystroke, caches that value, and from then on ignores anything typed on the keyboard, vs. a program that ignores every other keystroke.
The programmer tells the compiler which locations are associated with peripherals with the "volatile" flag. The compiler that it is permitted to do all kinds of clever caching optimizations for things in RAM and ROM, but "volatile" indicates data locations that are *not* normal RAM or ROM. This tells the compiler to *always* read or write values only the *exact* number of times the program actually specifies a read or write, and to keep them in the same order.
Sometimes the keystroke buffer is simulated by an interrupt routine that talks to the keyboard using a more complicated protocol, then the interrupt routine deposits the result into a particular byte in RAM.
To the application program, it doesn't matter if the keystroke buffer is a piece of hardware, or simulated by an interrupt routine. Since the programmer who wrote the application intends for that location to be treated as if it were a hardware peripheral, even in the case where it is really a bit of normal RAM being fed by an interrupt routine, that programmer continues to mark it as "volatile".
Do you think this approach (after a considerable amount of polishing) would be helpful in understanding? Or is it just more confusing ? Did I go into too much / not enough detail ? (Perhaps I should describe an even simpler, semi-fictional machine ?) -- DavidCary 05:36, 16 July 2005 (UTC)
How would you use "volatile" in a program that didn't touch hardware ? (I use it to mark (a) peripheral registers, (b) bytes of RAM that are read or written by some interrupt routine pretending to be peripheral registers (or perhaps pretending to be a parallel processor). Is there a (c) another way of using "volatile" ?)
I agree that "const" is very useful in programs that don't touch hardware -- because it makes some things more readable. But I pretend that things marked "const" behave as if the compiler puts them in ROM, even when I know they are really in RAM (or perhaps optimized away to nothingness). How is that any more misleading than all the other as if C things? I'm pretty sure there is no such thing as a const_cast operator in plain ANSI C. The const_cast operator is a C++ thing, and I am still mystified by it.
Would you agree that real peripheral registers must always be marked with "volatile" and/or "const" to get the compiler to handle them correctly ? I think it's helpful, when reading an encyclopedia article about some new-to-me concept, to read about why something is (objectively) necessary in some cases, before I read about how it is (subjectively) "more readable" in other cases.
-- DavidCary 12:28, 18 July 2005 (UTC)
const
-ness does not imply that the variable as it is stored in the
computer's
memory is unwriteable. Rather, const
-ness is a
compile-time construct that indicates what a programmer may do, not necessarily what he can do."Static validation of object immutability would be a good alternative title, albeit a bit too long. Wouter Lievens 17:08, 18 July 2005 (UTC)
The article used to say the following, in the section "restrict in C99":
Does anyone know what the writer had in mind? After all, in the example given (which is still in the current revision, but won't be for much longer, if I remember to come back and take it out), it seems to me that the compiler would be able to change
void foo(int *);
int bar(int *a)
{
const int *b = a;
foo(a);
return *b; /* const, non-volatile value cannot have been modified by the intervening code */
}
into
void foo(int *);
int bar(int *a)
{
int ret = *a;
foo(a);
return ret;
}
without any restrict
-based contortions on the programmer's part. A Google search for "strong const" doesn't turn up anything enlightening. --
Quuxplusone 04:22, 22 August 2007 (UTC)
The article states "Similarly, C++ does not have any feature equivalent to Java's final modifier for methods, although its effect on classes can be simulated by a clever abuse of the C++ friend keyword.[3]"
It needs clarifying to the non-guru C++ users, that the default behavior for C++ member functions is to be hidden, but not overridden. There is no method hiding in Java. Someone might think that you can't prevent overriding in C++, which is not true. The fact is how ever that you cannot prevent hiding in C++. —Preceding unsigned comment added by 84.36.31.228 ( talk) 13:20, 31 October 2007 (UTC)
Removed from the article:
volatile
pointers, though their applications are rarer:
// Set up a pointer to a read-only memory-mapped register that
// contains a memory address for us to dereference
const int * volatile const tableLookup = reinterpret_cast<int*>(0x8004);
int currentTableValue = *tableLookup; // Dereference the memory location
int newTableValue = *tableLookup; // Dereference it again
tableLookup
pointer can change implicitly, each dereference might go to a different location in the
lookup table, so currentTableValue
is not necessarily equal to newTableValue
.The code doesn't match the comments, and the accompanying English text glosses over the key point of confusion. The semantics of the code are: Take the value 0x8004 and convert it (at compile time) to a pointer; at runtime, store this pointer value in memory (at a location named "tableLookup
"; dereference it twice, but allowing for the possibility that someone else could be overwriting "tableLookup
" in between accesses. (C and C++ are fuzzy on what exactly "volatile" means, but "someone else overwriting it" (plus "someone else reading it", which is irrelevant here) is a good enough approximation of how modern compilers treat it.)
However, since the symbol "tableLookup
" has internal linkage, there is no plausible way for anybody else to be modifying the value at that address (which was determined randomly by the compiler, if it exists at all; remember, &tableLookup
is not (int*)0x8004
; that's the value stored in tableLookup
). Since tableLookup
was declared const
, the C++ compiler is not even required to allocate storage for an object called tableLookup
at all! You'll see this happen if you remove the volatile
qualifier. I don't think there's any wording in the C++ standard that forces the compiler to allocate space for tableLookup
just because it's volatile
.
The critical points about the semantics of the above code are: The value stored at 0x8004 is const
and can be assumed not to change. The tableLookup
object itself (if it exists) is const volatile
. The compiler (theoretically) cannot assume that the assignment to currentTableValue
reads from address 0x8004. But the comments and English commentary don't seem to match these points, and the code itself is kind of pointless, so I suspect that the original writer was laboring under misconceptions about the semantics of what he wrote. --
Quuxplusone (
talk) 07:22, 13 May 2008 (UTC)
The reference numbering in the article is wrong, but I don't want to edit the article as I lack the expertise.
Reference pointer [3] at the end of the section "final and JAVA" refers to number "4." in the reference list. This is caused by the fact that the ID of reference number 3 ("endnote_cleverabuse") is not used in the article.
92.233.157.159 ( talk) 20:25, 23 May 2008 (UTC)
I find it odd that const_cast<>() is described as a "loophole", and given the air of a weakness introduced by C++ ... while in reality it's supposed to close the dangerous "loophole" which is plain old C-style casts – which in turn is not mentioned at all! The term "loopholes" should probably not be used at all – it makes it sound as if a programmer is never supposed to be able to break a const. As far as I can tell, that was never Stroustrup's goal with const. JöG ( talk) 21:02, 9 February 2010 (UTC)
"While const methods can be called by const and non-const objects alike, non-const methods can only be invoked by non-const objects." Shouldn't "by" be replaced by "on"? Rubix ( talk) 12:38, 18 November 2011 (UTC)
«Following usual C convention for declarations, declaration follows use, and the * in a pointer is written on the pointer, indicating dereferencing (...) Thus const modifies the name to its right.»
I think this assertion must be more explicit: In which sense does it modify the name? What exactly is it meant with 'name'?
Moreover, immediately after, it appears incomprehensible the jump to C++, since this language is considered and explained in the next section.
Hence, it is not clear if the subsequent examples are referred to C or C++. But, above all, it is undecipherable how you can see in this example:
«int const * ptrToConst can thus be read as "*ptrToConst is a int const" ...»
where the above mentioned modification to the name lies (i.e., if compared with the examples of the successive section "C++ convention", the difference 'name' vs 'type' modification is not evident). — Preceding unsigned comment added by Filipsnew ( talk • contribs) 22:37, 13 September 2016 (UTC)
Hello fellow Wikipedians,
I have just modified 2 external links on Const (computer programming). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
{{
dead link}}
tag to
http://archive.adaic.com/standards/83lrm/html/Welcome.htmlANSI/MIL-STDWhen you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{
Sourcecheck}}
).
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 23:57, 29 November 2016 (UTC)
Hello fellow Wikipedians,
I have just modified one external link on Const (computer programming). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 10:39, 12 August 2017 (UTC)