Explain alloc/init occurring twice

Question

I realize this question may sound dumb, but just bear with me. I built an app to help new developers wrap their head around memory retention on the iPhone (no ARC yet). It is plain and simple, 4 buttons, init, access, retain, and release. Pretty self explanatory. I am displaying what the retain count for my string object that is the target of our poking and prodding. (Please no lectures on use of [myVar retainCount], I already know)

This stuff will never make it into actual apps, just toying with it for fun and hopefully help someone learn how memory works. My retain and release all work great. My question is that why does my retain count drop back to 1 if I call myString = [[NSMutableString alloc] init]; again. I can boost my retain count to 40, but after calling alloc/init I go back to zero. I am not leaking anywhere, just curious what happens to myString if/when alloc/init is called on it again.

Answer 1

My question is that why does my retain count drop back to 1 if I call myString = [[NSMutableString alloc] init]; again?

Because you are failing to understand a very basic concept of Objective-C; myString is not an instance of an NSMutableString, but a reference to an instance. If you were to:

myString = [[NSMutableString alloc] init];
myString = [[NSMutableString alloc] init];

You now have two instances of NSMutableString, one leaked.

If you:

myString = [[NSMutableString alloc] init];
otherString = myString;

You now have a single instance of NSMutableString with two references.

In all three allocations, the NSMutableString instance will have a +1 retain count and, thus, you must balance each with a single release or you'll leak.

Treating retain counts as an absolute count is a path to madness. Or, at best, the scope of usefulness of the absolute retain count is so limited that learning about it is not applicable to real world iOS programming.

---

This bears repeating:

The retainCount of an object is tricky business.

If you were to continue down this path, you should be aware of the following details:

• retainCount can never return 0
• messaging a dangling pointer is not guaranteed to crash
• retain count cannot be known once you have passed an object through any system API due to implementation details
• any subclass of any system class may have an unknown retain count due to implementation details
• retain count never reflects whether or not an object is autoreleased
• autoreleases is effectively thread specific while the retain count is thread global
• some classes are implemented with singletons some of the time (NSString, certain values of NSNumber)
• the implementation details change from platform to platform and release to release
• attempting to swizzle retain/release/autorelease won't work as some classes don't actually use those methods to maintain the retain count (implementation detail, changes per platform/release, etc..)

If you are going to teach retain/release, you should be treating the retain count as a delta and focus entirely on "If you increase the RC, you must decrease it".