A Deficiency of the C Preprocessor

[mike knudsen]

> >>As for compile vs. run time initialization of arrays:  A compiler I
> >>use creates code for all the initializations in the program ...
> >>Even worse, when an array is initialized, this compiler generates a line
> >>of code to initialize each entry, rather than an image of the array and
> >>looping code.
> >That sounds like a pretty poor compiler to me.  Whose is it, that
> >we may all avoid buying it?
> 
> I have never seen a C compiler that does this, but I know of another
> supposedly powerful language compiler that does. And of course there
> If I say:
> foo(){
> 	static int bar=0;
> 	...
> then 'bar' must be set to zero sometime before the first call to 'foo', and
> must *not* be set to zero on subsequent calls to foo. On braner's compiler,
> does this work, and if so, how? Does the compiler put 'CLR bar' into a
> separate code area which is executed at startup? This sounds like more
> trouble than real initialization...

How else to init this?

He may be talking about the OS9 Level I C compiler from Microware,
which I use all the time at home.  It does indeed go thru
agonizing space and time-consuming initializations on startup.
The reason for this is that OS9 C is required to produce
re-entrant, sharable object programs.  That is,
after I've been running such a program for a while, another
process or user can start up that same program.
He will use the same copy of pure code in RAM as I've been,
but he has to get his own data area initialized from scratch.

Unforch, this C doesn't have any "read-only" or "ROMable" declarations
for initialized data that you promise not to alter while running.

Since the program I'm writing will never be shared, I'd love to
get around this waste, but ....

-- 
Mike J Knudsen    ...ihnp4!ihwpt!knudsen
"It's like trying to get to sleep at the Intergalactic
Spaceport Hotel -- waiting for the being in the room above
to drop the Nth shoe, and you don't even know what N is."