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

> int f_()
> {
> static integer i;
>
> for (i = 1; i <= 100; ++i) { }
> return 0;
> }


Mark Hopkins <mark@omnifest.uwm.edu> writes:
> A decent compiler should optimize this to
>
> int f_() { return 0; }


Agreed, but the loop body was not the point of this discussion. The
code fragments in this example were merely to illustrate that f2c maps
FORTRAN loop control variables to storage class static int, and
futhermore, that many compilers generate code several times slower for
loops with static loop control variables.


> 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; }


Yes, that's precisely the point. There's no disagreement here.


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


Compilers are not required to perform this optimization, though some
programmers clearly have this expectation, as evidenced by your
comments.


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


Your understanding may or may not be correct, and you may want to
verify the output of your compiler. Some compilers perform this
optimization. Currently, the majority of C compilers do not.


Regards,
Christopher Glaeser cdg@nullstone.com
Nullstone Corporation http://www.nullstone.com
--

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