Re: Really stupid c question
Re: Really stupid c question
- Subject: Re: Really stupid c question
- From: Brian Williams <email@hidden>
- Date: Thu, 11 Apr 2002 13:48:25 -0700 (PDT)
Thanks for everyones response.
As guessed, I was trying to allocate the array in the init method of the saver.
Problem is that I didn't know how to allocate the array without knowing the
screen size. I guess I will look in to using an image rep but I remember seeing
a ton postings about getting access to the bits not being easy. I thought an
array would be the easiest.
Thanks again
Brian
--- Andy Lee <email@hidden> wrote:
>
At 12:09 PM +0200 4/11/02, Ondra Cada wrote:
>
>On Thursday, April 11, 2002, at 11:59 , Brian Williams wrote:
>
>>When I try to make a BOOL array like this ->
>
>>BOOL test[786432] /*1024 *768 ==786432*/ it crashes. I am guessing that I
>
am
>
>>going out of the local memory space? or something like that.
>
>
>
>Hmmm, is it local or global? If former, it might be the reason -- I
>
>am not sure of the stack space, but it is quite possible there's no
>
>a free M there. Though, there should be no problem with a global M;
>
>if so, there would be anotehr problem too.
>
>
I reproduced the problem pretty easily. All I had to do was declare
>
the large array in a method and enter the method. I suspect Ondra is
>
right, there was some upper limit on memory that the program was
>
hitting when it tried to allocate that big block of memory on the
>
stack.
>
>
When I moved the array outside the method (making it global) I didn't
>
have the problem. This makes sense, because the memory would have
>
been allocated statically when the application launched.
>
>
In Java, one doesn't get the same problem with something like
>
"boolean[] test = new boolean[786432]", because all Java arrays are
>
objects, and therefore allocated from the heap rather than the stack.
>
>
There might be a way to tweak memory settings for your program to
>
avoid this problem, but I don't know the low-level mechanisms to do
>
so. One programmatic workaround would be to use the C function
>
malloc() to allocate the memory for the array, being sure to
>
explicitly deallocate the memory when you are done:
>
>
BOOL *test = malloc(786432 * sizeof(BOOL));
>
>
... blah blah ...
>
>
free(test);
>
>
Because of the way pointers and arrays are related in C, you wouldn't
>
have to change any of your array code. You could still refer to the
>
elements of the array as test[0], test[1], and so on.
>
>
The more proper Cocoa way would be to use NSZoneMalloc() and
>
NSZoneFree() instead of malloc() and free(). They are documented in
>
/System/Library/Frameworks/Foundation.framework/Versions/C/Resources/English.lproj/Documentation/Reference/ObjC_classic/Functions/FoundationFunctions.html.
>
>
Whether the humongous array of BOOLs is the appropriate data
>
structure for your needs is a separate question. As always, "it
>
depends."
>
>
--Andy
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
=====
Brian Williams
homepage == <
http://chromaticgray.com>
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.