Talk:Const (computer programming)

Other Languages

Anyone know of other languages that support this? Wouter Lievens 10:47, 28 Apr 2005 (UTC)

Strange, I never noticed before you asked: c++ is the only major language I can confirm uses const variables... Maybe it's because it sounds like such an oxymoron. Java seems to have a const keyword, but doesn't use it. Java's final keyword is similar when used with a member variable however. I believe that const may be valid C now since C99, but it'd be better to double-check that. I know of no other language with anything anologous to mutable. Const correctness seems to be a wholly C++ phenomenon. TheIncredibleEdibleOompaLoompa 17:19, 2005 Apr 28 (UTC)

C# also has a const keyword (and a readonly keyword), though it really has nothing like const correctness in C++. IIRC, it makes a reference immutable, not the object itself. OracleofTroy

Yeah Java has final and C# has const but it's not the same. What really matters (in this article) is the const correctness of methods. Wouter Lievens 07:48, 12 May 2005 (UTC)

The const keyword exists since ANSI C. However, I consider it bad that the article uses "C/C++" or "C and C++" and then goes on using examples that work with C++ only (except the first). --82.141.48.135 4 July 2005 07:25 (UTC)

You're right that the article should be more clear. ANSI C doesn't support const-correctness in the most important sense: applying const to object methods (because it doesn't support objects as such). --Flex July 4, 2005 11:24 (UTC)

Are you sure about that? Let me transcode the C++ code to C:

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! */
}

If you try to compile this with GCC (for example) you get a warning for the last line: "warning: passing arg 1 of pointer to function discards qualifiers from pointer target type". So in my opinion, you can have this kind of "const correctness" in C, too. --82.141.48.146 7 July 2005 09:51 (UTC)

Very few would attempt to write C++ code using C :-), but your point is well taken nonetheless. ANSI C does support const-correctness as far as it goes. Among object-oriented languages, C++ natively supports const-correctness with objects whereas Java and C# do not. --Flex 12:59, July 13, 2005 (UTC)

Immutability

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)

Const correctness is a programming technique that maximizes the use of immutable objects and allows for a simple design by contract. It applies in several programming languages, but the only one in widespread use is C++, which is what the bulk of this article covers. I don't think they should be merged necessarily, but I wonder if this article belongs in the Wikipedia rather than a Wikibook on C++. --Flex 11:40, 23 Jun 2005 (UTC)

While I am not C++ guru, this article, it seems to me, is little too verbose. For example, it says "const char *p" is the same as "char const *p", and this is clearly redundant; we are not writing a tutorial. Besides, the article seems to simply have random facts related to const rather than one specific idea (Actually I am not quite getting what this article is trying to say :) For instance, the discussion about volatile seems off-topic; if I understand correctly, it's basically the marker for lessening aggressive optimization. I don't believe that we can simply the content of this page to immutable object without any revision. But I still think it makes more sense to give some context, and for this the merger may help. What do ya think? -- Taku 12:38, Jun 23, 2005 (UTC)

Well, the volatile section is there because C++ also supports "volatile correctness," but its application is much rarer. (Consider: const_cast is so named because it is usually used to strip the const qualifier, thought it can strip volatile qualifier, also. Calling it qual_cast [or something like that] apparently seemed like overkill to the C++ committee.) If it is determined that const correctness deserves its own article, volatile correctness also make an appearance but as a subsection rather than its own article because its use is rare and its usage syntax is basically the same as const's.

Anywho, you're right that the article does tend more toward tutorial and loses sight of explaining const correctness as a concept. Let me try to make some revisions to correct that. Then we can decide if it needs to be merged. Personally, I think the concept of const correctness deserves its own page, but I could be persuaded. --Flex 13:13, 23 Jun 2005 (UTC)

There's an important difference, in that an immutable object is an abstract concept, for it can be enforced (badly) using conventions rather than using language techniques. Const correctness is a technique for implementing partial static verification of object immutability. However, I (as article creator) see no reason why this information cannot be integrated into immutable object. So go ahead if you want. Wouter Lievens 13:40, 23 Jun 2005 (UTC)

Ok, I (as major rewriter) have made the promised changes. What sayest ye now? --Flex 14:28, 23 Jun 2005 (UTC)

I am still not so sure. For one, is there any relation between a value with const and method with const, aside from the use of a term const? When discussing method with const, I think we also have to talk about mutable, but it seems to be beyond the scope of this article. I rewrote the intro a bit. Please correct me if I have missed something. -- Taku July 4, 2005 19:37 (UTC)

const, volatile, and hardware

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 computer 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)

Hi, David. As an embedded programmer myself, I think this approach would actually be misleading because const and volatile have uses in programs that don't touch hardware. In particular, the part about const indicating what a compiler can put in ROM is highly compiler-specific behavior (i.e., the standard that defines the language doesn't present it that way, I'm almost positive). In fact, that might be an incompatible extension because the const_cast operator is supplied explicitly to strip const-ness from an object. All this is to say that const correctness is more about program readability and design than about low-level interactions with hardware. --Flex 18:20, July 16, 2005 (UTC)