Memory Allocation on NSMutableArray Example


#1

On p.36 example, memory is allocated inside the loop:

for (i=0;i<10;i++){
NSNumber *newNumber=[[NSNumber alloc] initWithInt:(i*3)];
[array addObject:newNumber];
}

… but never seems to be released afterwards (objects allocated by alloc are not in the autorelease pool as stated p.73). Does it mean that the code printed on p.36 has memory leaks?


#2

[quote=“Stephane”]On p.36 example, memory is allocated inside the loop:

for (i=0;i<10;i++){
NSNumber *newNumber=[[NSNumber alloc] initWithInt:(i*3)];
[array addObject:newNumber];
}

… but never seems to be released afterwards (objects allocated by alloc are not in the autorelease pool as stated p.73). Does it mean that the code printed on p.36 has memory leaks?[/quote]

You seem to have a keen eye, now you just need some more patience :slight_smile:

See page 70.

EDIT: Oops, that was for some other code… so on second thought, page 37 says: “The array does not make copies of the NSNumber objects. Instead, it simply keeps a list of pointers to the NSNumber objects.”, so releasing them would make all the numbers in the array disappear, don’t you think so?


#3

[quote=“whoami”]

You seem to have a keen eye, now you just need some more patience :slight_smile:
(…)
On second thought, page 37 says: “The array does not make copies of the NSNumber objects. Instead, it simply keeps a list of pointers to the NSNumber objects.”, so releasing them would make all the numbers in the array disappear, don’t you think so?[/quote]

Thank you for dealing with my impatience :wink:

Of course, releasing them would make all the numbers in the array disappear. However, not releasing them will issue a memory leak to my understanding, when the program exits. I would have added something like [array release] before the [pool drain], or maybe added a [newNumber autorelease] inside the loop. Am I correct? I just started learning objective-c and I am confused by the book I read before Hillegass.


#4

[quote=“Stephane”][quote=“whoami”]

You seem to have a keen eye, now you just need some more patience :slight_smile:
(…)
On second thought, page 37 says: “The array does not make copies of the NSNumber objects. Instead, it simply keeps a list of pointers to the NSNumber objects.”, so releasing them would make all the numbers in the array disappear, don’t you think so?[/quote]

Thank you for dealing with my impatience :wink:

Of course, releasing them would make all the numbers in the array disappear. However, not releasing them will issue a memory leak to my understanding, when the program exits. I would have added something like [array release] before the [pool drain], or maybe added a [newNumber autorelease] inside the loop. Am I correct? I just started learning objective-c and I am confused by the book I read before Hillegass.[/quote]

Lesson learned: never write something without trying it first, i.e. I just added [newNumber release]; and the program didn’t crash and printed all the numbers like it did before…

And another thing, seems like the wisdom at page 73 isn’t always true:

So I sprinkled some NSLog(@"%@ retain count = %ld", newNumber, [newNumber retainCount]); before and after the release and got some interesting numbers back:

Wtf? retainCount is 2 (3 after adding it to the array)? But he said it should be 1… and then at number 15 the ratainCount, sort of weird, is 2 (respectively 1)?!

Jeez, and I always thought I understand this stuff at least a bit…


#5

Thank you for your further testing! As I far as I understand now, we should indeed release “newNumber” once it has been added to the array. Retain count sequence would then be like this: 1 > 2 > 1 (alloc > add to array > release) and pointers will be still kept as long as “array” needs them.

As for the weird retain count behavior of numbers below 15, I once read it is a compiler optimization issue. By default, the compiler preloads the intergers 0-15 with a retain count of 1 for offering a faster access to these numbers (these are the numbers are the most frequently used)… or something like that…