rrw@naucse.UUCP (Robert Wier) (02/11/89)
I have been asked to pursue this question by a number of people learning to use (specifically) Mac LightSpeed C: There appears to be a 32k limit on data structures. Not too suprising considering the limits of the 68k index register structure. I have gotten around this problem in Pascal programs by doing allocate and dispose operations. Is there something equivalent in C? Or is there a more elegant technique (for example, on researcher here would like to have a 512 * 512 array). Not being a C programmer, I would appreciate an answer in words of one syallable :-). Thanks! -Bob Wier at Flagstaff, Arizona Northern Arizona University ...arizona!naucse!rrw | BITNET: WIER@NAUVAX | *usual disclaimers*
folta@tove.umd.edu (Wayne Folta) (02/11/89)
Oops, I amde a mistake in my previous example--it would work for a 1-D array, but not 2-D. Check out your LightSpeed C 3.0 User's Manual, pg. 219, which has a 3/4 page sample. Wayne Folta (folta@tove.umd.edu 128.8.128.42)
ge@phoibos.UUCP (Ge Weijers) (02/13/89)
In article <1158@naucse.UUCP>, rrw@naucse.UUCP (Robert Wier) writes: > There appears to be a 32k limit on data structures. Not too suprising > considering the limits of the 68k index register structure. I have > gotten around this problem in Pascal programs by doing allocate and > dispose operations. Is there something equivalent in C? Or is there > a more elegant technique (for example, on researcher here would like > to have a 512 * 512 array). The problem lies partly with the MC68000, and partly with the compiler writers. Some facts: 1) the mac system limit global data (variables) to 32K. 2) no such limit exists for malloc'ed storage. 3) the 68000 uses 16 bit offsets in indexed addressing 4) compiler writers can work around this quite easily. The LSC compiler is not a bad compiler, but in this resepect it could use some improvement. A 1000 x 1000 'matrix' is easily created: double *matrix[1000]; int i; for(i=0;i<1000;i++) matrix[i] = (double *)calloc(1000,sizeof(double)); this creates an object that is not equivalent to double matrix[1000][1000]; but can be accessed similarly. 'matrix' is an array of pointers that each point to an array of 1000 doubles Hope this helps. Ge' Weijers KUN Nijmegen, the Netherlands UUCP: ge@cs.kun.nl
fgz@lakart.UUCP (Federico Genoese-Zerbi) (02/13/89)
From article <1158@naucse.UUCP>, by rrw@naucse.UUCP (Robert Wier): > There appears to be a 32k limit on data structures. Not too suprising > considering the limits of the 68k index register structure. I have > gotten around this problem in Pascal programs by doing allocate and > dispose operations. Is there something equivalent in C? There is. However, try the following: ptr = (variable type *)NewPtr(size needed); the C allocators used in Lightspeed end up calling NewPtr anyway. To deallocate try: DisposPtr(ptr); > Or is there > a more elegant technique (for example, on researcher here would like > to have a 512 * 512 array). > > Not being a C programmer, I would appreciate an answer in words of > one syallable :-). Look in the addendum to Lightspeed C 2.14 for a more detailed example or if you have THINK C 3.0, they have examples right in the manual. > > Thanks! No Prob. Federico {xait, mirror, cfisun}!lakart!fgz
suitti@haddock.ima.isc.com (Stephen Uitti) (02/14/89)
In article <1158@naucse.UUCP=> rrw@naucse.UUCP (Robert Wier) writes:
=>... LightSpeed C:
=>
=> There appears to be a 32k limit on data structures. I have
=> gotten around this problem in Pascal programs by doing allocate and
=> dispose operations. Is there something equivalent in C?
mlalloc(). One would normally use malloc(), but malloc
historically takes an "int" - which is 16 bits in LSC. mlalloc()
takes a long. I have written stuff with 300KB arrays in LSC. It can
be a little tricky debugging it, due to memory (or lack thereof)
problems. Many people use the Mac OS calls to do memory stuff. I try
to use standard C where I can. I've always thought of malloc() as
part of the language. PC's solve this with farmalloc() - sigh. I
vaguely recall having to declare void *mlalloc(); so that the cast
would work right.
=> Or is there
=> a more elegant technique (for example, on researcher here would like
=> to have a 512 * 512 array).
Maybe something like:
foo = mlalloc(sizeof(int[512][512]));
if (foo == NULL)
abort(); /* or whatever, but check! */
foo[30][25] = 6;
=> Not being a C programmer, I would appreciate an answer in words of
=> one syallable :-).
=> -Bob Wier
Sorry, mlalloc() has more than that. The manual describes it,
though. Watch for include files, libraries, etc. Always use prototypes.
Stephen.karl@haddock.ima.isc.com (Karl Heuer) (02/16/89)
In article <423@lakart.UUCP> fgz@lakart.UUCP (Federico Genoese-Zerbi) writes: >From article <1158@naucse.UUCP>, by rrw@naucse.UUCP (Robert Wier): >>I have gotten around this problem in Pascal programs by doing allocate and >>dispose operations. Is there something equivalent in C? The library routines malloc() and free() are the usual way of doing this. >There is. However, try the following: > ptr = (variable type *)NewPtr(size needed); >the C allocators used in Lightspeed end up calling NewPtr anyway. To >deallocate try: > DisposPtr(ptr); Is there any good reason to use these rather than the standard interface? If the only answer is that it avoids one function-call overhead, then I suggest that (a) portability is important, even if you have no current plans to port this program, and (b) malloc() and free() ought to be implemented as macros on that system. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
fgz@lakart.UUCP (Federico Genoese-Zerbi) (02/17/89)
From article <11781@haddock.ima.isc.com>, by karl@haddock.ima.isc.com (Karl Heuer): > In article <423@lakart.UUCP> fgz@lakart.UUCP (Federico Genoese-Zerbi) writes: >>From article <1158@naucse.UUCP>, by rrw@naucse.UUCP (Robert Wier): > The library routines malloc() and free() are the usual way of doing this. > > Is there any good reason to use these rather than the standard interface? If > the only answer is that it avoids one function-call overhead, then I suggest > that (a) portability is important, even if you have no current plans to port > this program, and (b) malloc() and free() ought to be implemented as macros on > that system. Your points are well taken. Consider the following issues however: (1) Most macintosh programmers I know (myself included) are very used to looking at Macintosh code. NewPtr() and DisposPtr() believe it or not, make for more readable code. (2) For the purpose of portability, NewPtr() and DisposPtr() replacement are the least of your worries. In the worst case you can just macro them out. The toughest task is writing code that does what things like Get/WaitNextEvent(), FindWindow(), ctl manager stuff, etc. I ported a mac application to a Sun workstation under X-Windows, and it was a hairy mess to deal with. A final note.....If you are going to be doing a lot of memory allocating/ deallocating, you should use NewHandle() and DisposHandle(), some calls to MoreMasters() at the beginning of your code (There is a Technical Note outlining how to determine how many to use) and HLock() and HUnlock() when dereferencing/done dereferencing. Your memory will thank you for it after a while (i.e. it won't get all fragmented). > Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint Cheers, Federico
monk@madhat.UUCP (Tom Bowden) (02/21/89)
Sorry to barge in like this. I have a problem. I ineed to access the errorlevel as it exists upon entrance to a c program. I am trying to simulate IF ERRORLEVEL nnn in C, or assemble. Can anyone help?