🚀 go-pugleaf

In article <140877@sun.Eng.Sun.COM| chased@rbbb.Eng.Sun.COM (David Chase) writes:
|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.
....

This is fine -- if C++ [as a whole] is willing to move away from the 
traditional "un*x" model of separate compilation, linking .h, .c files
etc.  -- Its just that lots of compromises have been made to the language
already to make it fix into this traditional C-like model of compilation
and linking.

The problem I see it, if you give the compiler all this extra #pragma 
information, where does the compiler store the pragma information such
that separately compiled modules can access it?  -- I guess the #pragmas
could go into the .h files, further weakening the distinction between
interface and implementation.  [And leading to even longer .h compilation
times] Otherwise, one has to add new fields in the
.o files, or add an additional database of information kept on a 
project-wide basis....

Optimizations based on const follows in a straight forward manner from const'
ness -- if compilers can rely on const on a contractual basis, and require no 
information from a programmer beyond what programmer's currently are
providing.  Optimizations based on const also encourage good programming
practice of declaring const on const things.

....Alternatively, maybe its just time to admit that the C-model of separate
compilation/linking is done for, and toss out the C++ language hacks based
on those restrictions.  But please, lets not get into a worse of both 
worlds situation where the language hacks remain, but other decisions are
made forcing C++ compilers towards auxiliary databases of information.