1

I am new to Objective-C and have come by 2 problems of the same sort already when freeing memory. Here is:

NSAutoreleasePool * pool = [[NSAutoreleasePool alloc]intit];
//^^ NSAutoreleasePool is unavailable: not available in automatic reference counting

[lord release];
//^^ Same error as NSAutoreleasePool

I am not sure why this is not working, it seems to work for others. Anyway if I could get some help on this that would be fantastic, thanks so much!

Inder Kumar Rathore
  • 39,458
  • 17
  • 135
  • 184
JeremyF
  • 735
  • 3
  • 10
  • 19

1 Answers1

2

You cannot use retain/release/autorelease selectors manually when you use Automatic Reference Counting. Manual reference counting was the old way of memory management - now, you should always use ARC and forget manually sending 'release' messages, because they're inserted automatically by the compiler.

NSAutoreleasePool was replaced w/ the language-level construct @autoreleasepool: https://developer.apple.com/library/ios/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html

Edit: @autoreleasepool example:

Here you have 10000 objects in the memory until the parent autoreleasepool drains:

for(int i = 0; i < 10000; i++){
    NSString * s = [NSString alloc] initWithFormat:@"%d",i];
}

At its peak memory usage, this algorithm has 10000 NSStrings in the memory. However, consider the following variant:

for(int i = 0; i < 10000; i++){
    @autoreleasepool{
        NSString * s = [NSString alloc] initWithFormat:@"%d",i];
    }
}

This way, there's only one NSString at a time, which gets deallocated at the end of each iteration.

Tamás Zahola
  • 9,271
  • 4
  • 34
  • 46
  • Hmm, I see that I should be doing @autoreleasepool{} but could you give me an example? I am confused on how this should be used exactly. – JeremyF Sep 21 '13 at 17:11
  • 1
    Normally you shouldn't use autoreleasepool at all. However, if you have a loop, where you're instantiating many **temporary** objects, you should consider enclosing the loop body in an autoreleasepool block. This way, the temporary objects are deallocated each iteration, and the applications memory footprint remains moderate. But I emphasise that you should only care about this when creating many-many temporary objects. – Tamás Zahola Sep 21 '13 at 17:52
  • Edited my answer with an example. – Tamás Zahola Sep 21 '13 at 18:04
  • 1
    @TamasZahola also if you manually spawn a thread you typically need to provide your own autorelease pool. – Gabriele Petronella Sep 21 '13 at 18:29
  • Awesome! I completely understand how to use the auto release pool, very useful, doing the work for you. Would it make a difference if I put the @autoreleasepool{} around the for loop instead of inside it though? – JeremyF Sep 21 '13 at 22:44
  • @JeremyFrancis yes, that would make a difference with disastrous consequences: by putting the @@autoreleasepool block **around** the whole loop, all the temporary strings would remain in the memory until the whole loop finished. This means that at its peak, the memory would keep hold of 10000 NSStrings. Look at it this way: if you put the @@autoreleasepool inside the loop, then each iteration, the pool is drained, and the string is deallocated. If you put the loop inside the @@autoreleasepool, then the pool is drained only after the whole 10000 iterations completed. – Tamás Zahola Sep 21 '13 at 22:58
  • Awesome I am clear on all this now. Thanks so much for your help guys! – JeremyF Sep 22 '13 at 01:16