Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!lll-winken!sun-barr!newstop!sun!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Summary: "const" for the progammers, pragma for the compiler.
Keywords: const noalias #pragma register volatile
Message-ID: <140877@sun.Eng.Sun.COM>
Date: 17 Aug 90 19:22:11 GMT
References: <26909@pasteur.Berkeley.EDU> <11194@alice.UUCP>
Sender: news@sun.Eng.Sun.COM
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 32

Speaking not as a C++ expert (because I'm not) but as someone who
might care about what an optimizing compiler could infer from "const",
I think that #pragma's should be used to give the compiler hints to
enable optimization, and that "const" (and its ilk) should be used in
whatever sense is most helpful to programmers and program maintainers.

The reasoning goes like this -- (1) there's LOTS of things that a
compiler might want to know about the behavior of a subroutine, (2)
and it isn't clear that "const" is the most important of them, (3)
adding keywords or abusing combinations of existing keywords to get
the additional information is likely to result in confusing cruft
irrelevant to the correctness of the program (much like "register" in
the old days).  The choice of what is best to know about a program
could well vary from processor to processor or from compiler to
compiler, so it isn't clear that this should be standardized just yet.
Thus, don't make it part of a language that is being standardized.

For example, a procedure passed a pointer might modify it or not,
or might store it in a global variable for later modification or
examination.  Pass the address of a local to a procedure that stores
it in a global, and you can't eliminate tail-calls.  Even if a
procedure does assign through a pointer, it's good to know when it
doesn't store the pointer someplace where OTHER procedures can assign
through it.

It's also slightly useful, on a multiprocessor, to know if a
subroutine called from within a loop modifies global data.  It's much
easier to run the loop body in parallel if any subroutines called
within the loop don't modify globally visible (shared) data.

David Chase
Sun Microsystems