memory management question for obj-c

Discussion in 'Mac Programming' started by wrjohns, May 4, 2009.

  1. macrumors newbie

    OK, I understand how it works for using NS classes and even CF objects. What I'm not so sure of is ordinary C-style arrays.

    a) can we use malloc/free (in a Cocoa/Cocoa Touch application), or does all memory reservation *have* to come from the various frameworks?

    b) I surprised myself the other day by declaring what looks like a static sized array, but where the static length was actually a variable: (As far as I know, the following array declaration isn't legal in ANSI C)

    - (void)doSomethingUsing:(int)size
    int myArray[size][size+1];

    // stuff

    The above code fragment seems to work with no problems. Where is this memory coming from? It can't really be statically reserved at compile time, since "size" isn't known. But I'm also not allocating any memory here either.
  2. macrumors 68030


    a) you can malloc/free the array (remember you're storing pointers to objc objects, not objects).
    b) sounds like C99 variable length arrays. Personally I would recommend avoiding them, as their semantics are subtle and often unlike the rest of C, but they should work.
  3. macrumors 68040


    Using dynamic sizes in array declaration is a GCC extension to C. Read more here:

    It covers allocation and deallocation.

    You are welcome to allocate your own memory using malloc in Objective-C, and i am unaware of any special limitations on the iPhone or iPod Touch. You just have to do it right. That's the challenge. Keeping track of your pointers, the size you allocated to them, freeing them even on abnormal exit from a function, etc. is challenging. Is there a very good reason for you to do this instead of using an NSMutableArray?


    EDIT: I'm not too familiar w/ C99, so sizing this way may be supported in that standard. i have always thought of that has an extension, though.
  4. macrumors newbie

    Interesting. So I can do this, but I shouldn't keep any pointers around to a dynamic sized automatic array beyond its scope (which is true for static sized automatic arrays, so I'm not surprised).

    As for why not use NSMutableArray... yes, thats an option. Its actually the route I've been going so far. For multidimensional arrays, I'll have to do the index conversions myself. My main issues are the wordiness of the messaging syntax, fears about overhead, etc when I'm trying to implement a lot of numerical operations in what needs to be an optimized routine.

    I've read that NSMutableArray's arent really arrays after all. They seem to work more like circular doubly linked lists, with a cache pointer. Sequential for-loops will get you about the same performance as a traditional C array, but non-sequential access won't be so good. And if underneath the hood, I'm using the array as a 2D array...most of my accesses are going to be non-sequential.

    I suppose the 3rd option is to use NSData, let Cocoa worry about memory allocation, and just use the pointer it gives me to do my own thing.

  5. macrumors 68040


    Why not an NSMutableArray of NSMutableArrays instead of doing index math against a single array?

    If you need fast access at certain times, you can use:
    to get a C-style array, and loop through that, etc. quickly... If you make modifications to the array at that point (not manipulating the Objects pointed to, but the order, changing to different objects, etc.) you can then rebuild with:


Share This Page