rbutterworth@watmath.waterloo.edu (Ray Butterworth) (03/27/88)
(It's a bit late for me to submit this to X3J11, but if any of you
are about to send your comments in or have direct input to the
committee, please steal these ideas. They are not meant to support
the addition of noalias to the language at this time. They are
simply suggestions that I would like to see followed if we really
do get stuck with it.)
The type (const volatile int) is perfectly reasonable and refers
to an int whose value may change without warning by external
forces (e.g. interrupts) but whose value may not be changed
by the current code. Yet the word "const" has too many other
connotations, and the English expression "volatile constant"
is quite self contradictory. When the Standard says "const"
it does not mean constant.
Similarly when the Standard refers to a "noalias" object it does not
mean that the object has no aliases. For instance consider the
three auto variables "int x; noalias int *p=&x; noalias int *q=&x;".
This provides three separate aliases for "x", not "no alias".
What it really means is that for the duration of the noalias
qualifier (except at certain sequence points) the object may be
kept in cache memory without fear that accesses through another
pointer were intended to access this object.
The qualifier "volatile" is reasonably named already. (e.g.
Webster's New Collegiate describes it as meaning "fickleness
of disposition", or "difficult to capture or hold permanently".)
The qualifier "const" should be replaced either by a meaningless
word (e.g. "xyzzy") or by a word that more closely reflects its
intended meaning (e.g. "readonly" or "protected").
The qualifier "noalias" should be replaced either by a more
meaningless word or by a word that more closely reflects its
intended meaning (e.g. "cacheable").
If the words "readonly" and "cacheable" were to replace the
currently proposed "const" and "noalias", code would be much
more readable, and the Standard itself would be much easier
to understand.
If the Standard talks about a "cacheable" object one would
probably understand what they are describing. But when they
talk about a "noalias" object, or even worse a "non-noalias"
object, I, and I'm sure many other people, get quite confused.
A "non-cacheable" object is obviously one that the compiler
should not place into cache memory. A "non-noalias" object
is the same thing, but it certainly isn't as obvious.
For instance:
"strcpy(cacheable char *out, cacheable readonly char *in)"
means that the function is free to place either or both
strings into cache memory without causing any problems
(i.e. the strings shouldn't overlap), and that nothing that
the second argument points to will be changed by the function.
Now "strcpy(noalias char *out, noalias const char *in)"
might mean the same thing, but it isn't nearly as obvious.
From "Through The Looking Glass" by Lewis Carroll:
"There's glory for you!"
"I don't know what you mean by 'glory',"
Alice said.
Humpty Dumpty smiled contemptuously. "Of
course you don't -- till I tell you. I meant
'there's a nice knock-down argument for you'!"
"But 'glory' doesn't mean 'a nice knock-
down argument'," Alice objected.
"When _I use a word," Humpty Dumpty said,
in a rather scornful tone, "it means just what
I choose it to mean -- neither more nor less."
"The question is," said Alice, "whether you
_c_a_n make words mean so many different things."
"The question is," said Humpty Dumpty,
"which is to be master -- that's all."daveb@geac.UUCP (David Collier-Brown) (03/29/88)
In article <17834@watmath.waterloo.edu> rbutterworth@watmath.waterloo.edu (Ray Butterworth) writes: >by the current code. Yet the word "const" has too many other >connotations, and the English expression "volatile constant" >is quite self contradictory. The suggestion by Ray ("readonly" and "cacheable" to replace the proposed terms) is consistant with existing C naming. The notable example here is "static", which specifies something physical, and very specific. This is preferable to "private", which suggests its purpose but not its implementation. --dave -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.