Path: utzoo!mnetor!uunet!husc6!mailrus!ames!necntc!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Does extern "const" allocate storage?
Message-ID: <3241@haddock.ISC.COM>
Date: 30 Mar 88 19:16:51 GMT
References: <7712@apple.Apple.Com> <3034@haddock.ISC.COM> <613@mcrware.UUCP> <3117@haddock.ISC.COM> <3938@chinet.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 51

In article <3938@chinet.UUCP> dag@chinet.UUCP (Daniel A. Glasser) writes:
>In article <3117@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes:
>>In article <613@mcrware.UUCP> jejones@mcrware.UUCP (James Jones) writes:
>[original stuff deleted]
>>>Is this really true [since "const" really means "readonly", not "constant"]?
>>
>>An object which is declared const but not volatile can never be modified by a
>>correct program.  A conforming implementation is allowed to take advantage of
>>this knowledge, by putting it in read-only memory and/or by inlining it.
>
>I dissagree with Karl.  I'm looking at the draft standard right now, and I
>believe that const does not give the compiler the license to 'inline' it.
>[The dpANS does say in a footnote:] "The implementation may place a const
>object that is not volatile in a read-only region of storage."

I think it's covered by the as-if rule.  If I say "int const x=5;", then since
we seem to agree that the value can never change (otherwise the implementation
would not have the liberty to enROM it), a compiler ought to be able to
convert "return x;" into "return 5;".  To disprove this, you'd have to come up
with a strictly conforming program in which the optimized version produces a
different result than the non-optimized.

>[Section 3.5.2.4 in the Rationale] states that the compiler can cache this
>value, only reading it from storage once, though this does not guarentee that
>the value will not ever change in the running of the program.

I don't see that.

>The only time that a const value is known never to change (by the compiler)
>is when it is declared as 'const noalias'.

That paragraph is talking about a pointer.  It's true that the referent of a
(non-noaliased) "int const *" is not cacheable, because there could be a
non-const path to the same object (i.e. we may actually be dealing with an
"int *" that has been cast to "int const *").  However, I maintain that the
object declared by "int const x=5;" is cacheable.

>PS to KH: Please don't flame me so violently, huh?  I'm not posting out of
>spite.  And yes, our compiler converts i++ to ++i where it makes no
>difference.  I've encountered those that do not, and have learned not to
>depend on its being done.

Neither this nor my previous posting was a flame; I'm sorry if you took it
that way.  In fact, I always write "++i" rather than "i++" for essentially the
same reason (and for the related reason that "++i" is the more fundamental
operation, so I'm writing what I mean), even though I've never used such a
compiler.  But I still believe that any compiler that doesn't make such a
simple optimization is probably so lousy that it's not worth hand-optimizing;
you end up doing a lot of work for a small benefit.

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint