const and static (was: C vs. assembly...)

>From cdg@nullstone.com (Christopher Glaeser):
> int f_()
> {
> static integer i;
>
> for (i = 1; i <= 100; ++i) { }
> return 0;
> }


A decent compiler should optimize this to


int f_() { return 0; }


and, if it used inter-procedural control flow analysis, should
entirely remove the function and substitute each of its calls by the
constant 0.


At least, that was my understanding of what compilers are supposed to
do. So if this is a archetypical example of the problem with having
the "static" feature, I don't see the problem.


Even if there were statements inside the {}, it should still optimize
it by removing the "static", since having a static variable inside a
procedure which is assigned to before its first use and after its
declaration (and after any initializer) is exactly the same in effect
as having an auto variable instead.


However, I agree with you on the "const" feature -- but for different
reasons. Not only should the compilers be using the "const" feature,
but it shouldn't even have to have it because it should already be
doing expression evaluations to reduce all those expressions that can
be reduced at compile-time.


In the example you cite:
> #define ONE 1
> const int one = 1;
>
> int f()
> {
> x = ONE;
> y = one;
> }


this should compile to exactly the same thing as the following does:


int f() { x = 1; y = 1; }


I'd even go so far as to call it a hidden bug in the compiler if it
didn't, the Standard notwithstanding.


I actually do use const and enum (and bit fields) in place of #define
with this understanding in mind.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.