Couple questions, first
if i alloc 10 ints to some int* x
when it comes time to free them, do i need to tell it it was 10, or does it know?
#2 If i do int x[5];
And then pass that pointer to some struct which holds onto it and store that in some NSObject. When that NSObject is doing its dealloc, do I need to free that memory, or because it was made without using alloc is it freed automatically. Is it even safe to use non alloced memory outside the scope of where you allocated it?

Thanks!

1.) No, you don't. Depending on if you're using C++ or C, either delete [] x; or free(x) is fine.
2.) int x[5]; creates an array, not a pointer. It is allocated on the stack, so it will be freed when it goes out of scope. So, if you store a pointer to that array in a structure which persists beyond the scope of the array it is unsafe since the array no longer exists so the memory that the pointer points to could be anywhere.

kendric Wrote:if i alloc 10 ints to some int* x
when it comes time to free them, do i need to tell it it was 10, or does it know?

It knows. malloc keeps track of the addresses and sizes of memory allocations behind the scenes (it has to, so it can find a contiguous unallocated block of memory when you ask it for one), so all free needs is the base address of the allocation, and it can look up the rest.

kendric Wrote:#2 If i do int x[5];
And then pass that pointer to some struct which holds onto it and store that in some NSObject. When that NSObject is doing its dealloc, do I need to free that memory, or because it was made without using alloc is it freed automatically. Is it even safe to use non alloced memory outside the scope of where you allocated it?

Nope. This is actually a very different kind of "allocation" than what you get with malloc. malloc returns storage from the heap, which is disorderly but can remain relatively unchanging as your program executes. Declaring a local variable in a function specifies storage on the stack, which is reclaimed as soon as the locally stored variable goes out of scope (as in, when the function returns). Any pointer to local storage that escapes from that function will end up pointing to some random space on the stack that's likely to contain something different if you try to access it elsewhere after the function returns.

EDIT: Drat, beaten by mere seconds!

Thanks guys. That was what I needed to know.

Another question on this topic.
Which of the following is more kosher\expected behaviour

MyStruct *t;
//initialize t to some memory and set it up
someObject.myStruct=t;

where myStruct is an assignable property of type MyStruct*

option 1)
in the setMyStruct function it
a)frees the old pointer if it was not null(so this is assuming that whoever handed it to us at that point never expected to use it again)
b)sets its pointer = to the new pointer you passed in
The downside here is if somebody just wants to set the value, they have to malloc themselves an object, and pass it

option 2)
in the setMyStruct function
a)if we don't have an existing variable allocated, allocate one
b)copy the values over and have exclusive control over the pointers memory,
and not touch the pointer that was passed in(other then to copy values out of it)

Do you assume that someObject has taken responsibility for your pointer's memory and will free it later, or do you assume that it just copied the values and you should still worry about freeing the memory? I think its #1 but want to see what the suggested way of storing struct pointers is.

With #1 you have to do:
CGPoint *temp=malloc(sizeof(CGPoint));
CGPoint center=[self.unit center];
temp->x=center.x;
temp->y=center.y;
self.location = temp;

instead of just
CGPoint temp=[self.unit center];
self.location = &temp;//you might even be able to do &[self.unit center] here, not sure
but the memory ownership in this example isnt obvious to people it seems.

I am thinking of going with something like this. It removes all ambuguity. The main reason i need this is I need nullable CGPoints to represent an "off" mode

Does this look ok?

location shouldn't be a pointer at all. It should be just a regular variable. Then that code becomes


Notice the addition of a locationCleared member variable. It's just a BOOL.

Thats true. I could do that too. Thanks