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

mark@omnifest.uwm.edu (Mark Hopkins) wrote:


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


And if it does, you should quickly demand your money back for that
compiler. Const does not mean that this variable is to be treated as a
compile time constant. What it means is that the user of this
definition cannot modify it. That doesn't mean some other routine
won't.


As an example consider if you had some library and wanted to provide a
read only variable to users of the library. You could put an extern
const type var; in an include file for the outside world, but internal
to the library, use it without the const.


Unfortunately, C will let someone overwrite it by just making their
own extern type var;. Heck, C doesn't even care if you access it with
a completely bogus type. A good strongly-typed language should be
designed to not allow this. This lack of data hiding and strong type
checking are some of the reasons that C is really not a very good
language.


--

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