views:

58

answers:

4

In the code below, will tapsLable.text be deallocated when tapsMessage is released or does the assignment operator somehow increment the retain count so that tapsLabel.text continues to be available?

NSString *tapsMessage = [[NSString alloc] initWithFormat:@"%d taps detected", numTaps];
tapsLabel.text = tapsMessage; // tapsLabel is a UILabel object
[tapsMessage release];
A: 

It will not be deallocated.

dc
+1  A: 

tabsLabel.text is a property on tapsLabel. I think it's a string property that does [target copy] on assignment. Nevermind the details, yes, the assignment operator either increments the retain count or copies the value, so you can release tapsMessage and it is still available in tapsLabel.text.

Read more about properties here.

EDIT: looked up UILabel in the header, yes, it does a copy for the text property.

@property(nonatomic,copy)   NSString       *text;            // default is nil

EDIT: to expand on the important question in the comment

How does anyone know when to release and when not to if you have to look at the implementation details of every object you assign something to?

You just follow the memory management rules. The point of the refcounted environment is exactly that there is some "loose coupling" going on between the objects in terms of memory management. As long as you retain and release properly, it is not your concern whether someone else also retains and releases these same objects, as long as all involved parties have their retains/releases matched.

Jaanus
I'm new to objective-c but I know C. If the assignment operator sometimes results in a copy or an increment of the retain count, and sometimes it doesn't, that would make memory management extremely problematic. How does anyone know when to release and when not to if you have to look at the implementation details of every object you assign something to? (Just curious)
bhause
The rules are actually quite simple, once you get used to them. See here: http://developer.apple.com/mac/library/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmRules.html In your example retainCount for tapsMessage should actually not be increased since it is a copy, not a retain, operation. And as you see in memory mgmt guide, you do NOT have to look at implementation details to know when (not) to release.
Jaanus
Thanks everyone for your help and patients. I think it's all clear now.
bhause
You should also mark the best answer, whichever you choose, as accepted, part of Stackoverflow etiquette.
Jaanus
+2  A: 

Here's a tip

You can write the retainCounter for the object then you see what it is before and after the assignment.

e.g. NSLog( @"%d", [tapsMessage retainCount] );

That way you can answer such questions in the future by just writing out the retainCount as it always depends on how the property is declared.

Anders K.
The `retainCount` should rarely be looked at explicitly. In fact the documentation says not to use the `retainCount` method for inspecting memory management issues. See [here](http://developer.apple.com/mac/library/DOCUMENTATION/Cocoa/Reference/Foundation/Protocols/NSObject_Protocol/Reference/NSObject.html#jumpTo_18).
dreamlax
@dreamlax I know it is not intended for debugging, however it does give an insight in how reference counting works and that is the issue that the OP is facing.
Anders K.
Thanks for the retainCount logging tip. I'm sure I'll use that in the future. I think my initial confusion was because I did not realize that the assignment operator "=" would result in the calling of the accessor method. Once again, thanks for the help!
bhause
+1  A: 

In the first line, you have allocated and initialised an NSString. You own this object according to the memory management rules, which means you are responsible for releasing it.

In the second line, you are assigning the tapsMessage string the text property. This property (assuming tapsLabel is a UILabel) is declared with the copy attribute. For immutable strings (NSStrings), asking for a copy simply increments the retain count, since there is no need to make an actual duplicate of the data (the data can never change). Since UILabel has made a copy of the string, it has claimed ownership as well (objects can have more than one owner).

In the third line, you relinquish your ownership but the string still has one owner (the label), so the object is not deallocated.

dreamlax
"For immutable strings (NSStrings), asking for a copy simply increments the retain count, since there is no need to make an actual duplicate of the data (the data can never change)." -- great insight. Is this documented anywhere officially that this is how it works?
Jaanus
Thanks for the great help and explanation. I think it's all clear to me now.
bhause