Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!kth.se!news
From: d88-jwa@nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Need large array on Think C.
Message-ID: <1990May30.114952.230@kth.se>
Date: 30 May 90 11:49:52 GMT
References: <26645@<265986A9> <1232500001@ENS.Prime.COM>
Sender: news@kth.se  (News Administrator)
Reply-To: d88-jwa@nada.kth.se (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 43

In article <1232500001@ENS.Prime.COM>, J.COOK@ENS.Prime.COM writes:
> 
> There has been some discussion of a note from stoms@castor.ncgia.ucsb.edu

> >>done.  When I declare an array ('char arr[100][300]'), the complier
> >>gives me an 'illegal array bounds' error.  Is there any way I can

> I find it too bad that all solutions in C involve allocating the array
> at runtime and then referencing the variable through a pointer variable.
> The resulting loss of efficiency due to indirection is disappointing.

What do you think char foo[100][300] means anyway ? It's an array
of 100 references to 300-char arrays. You could use foo[100] as a
char pointer. So what's the big problem with allocating the block
containing the 100 pointers, and then allocating the 100 blocks in
a loop at the beginning ? You could always move the handle high,
lock it down down, and forget about it's handle nature, meaning that
the same code may be used for this technique (char ** foo) as for the
"ugly" (char foo [N][M]) way.

> It is particularly bad when you realize that compilers (both C and Pascal)
> tend to not perform cross-statement register tracking (I admit I am unsure
> about MPW).  The effect is that the pointer to the array must be reloaded

MPW C actually does some optimization. I like THINK C better, though,
for other reasons. And I'm not afraid of a little asm {} :-)

You could always declare a register char * variable, and assign it
before you wanted to use it multiple times, resulting in a guaranteed
performace increase.

> Dataflow analysis?  Flow analysis?  Code migration?  Constant subexpression
> optimization?  Loop invarient removal?  Cross-statement register tracking?

At least constant subexpression's done...

> Sigh.  It would seem to me that good code optimization could noticeably
> improve the performance of many applications.  Just by improving the code

Want to port gcc ? ;-)


	Jon W{tte, Stockholm, Sweden, h+@nada.kth.se