1

retain and autorelease questions.

// A
UIView *temp = [[UIView alloc] init];
myView = temp;
[temp release];

// B
myView = [[UIView alloc] init];

Do the two codes have no differences?

NSString *str = [NSString stringWithString:@"Hello"];
NSString *str = @"Hello";

And these two? I'm not sure about retain count yet. Thank you.

kubi
  • 48,104
  • 19
  • 94
  • 118
Boa
  • 367
  • 3
  • 13

4 Answers4

3

For the first example, they are very different. In first code chunk, the UIView given to temp has a retain count of 1 (thanks to alloc). When you release it on the third line, the MyView variable is now bad, because the object could be destroyed. If you want MyView to keep it, do:

MyView = [temp retain];

The second part of the first example will create an entirely new instance of a UIView, which has no relationship to temp.

In the second example, the stringWithString method will autorelease your string, meaning that it will be automatically released for you when the "release pool" is released, much later. You don't have to worry about releasing it. In the second line, however, the string is statically allocated. Retain counts and releasing are totally unnecessary with them.

Forgot to mention... check out the answer to this question for more about the retain/release rules.

Community
  • 1
  • 1
Tesserex
  • 17,166
  • 5
  • 66
  • 106
0

First part: It's not the same!

MyView will be released too, because you're just copying the pointer (retain count 0). In the second code MyView will have retain count of 1.

Second part: It's basically the same.

Felix
  • 35,354
  • 13
  • 96
  • 143
0

  1. Remember that the reference MyView just points to temp. So as soon as you release temp, this also affects MyView.

  2. The [NSString stringWithString:] is mainly used for copying other strings instead of referring to the memory address. E.g:

A:

NSString *string = someOtherString; // Copies the reference to someOtherString;

B:

NSString *string = [NSString stringWithString: someOtherString]; // Makes a copy of the other string.

theodorton
  • 674
  • 1
  • 6
  • 11
0

One useful thing, is that you can NSLog the retaincount, so that you can do testing on your own.

But back to your question...

IF MyView is a property, and you had referenced it with self.MyView and it was declared with retain or copy, your 2 statements are the same. If MyView is just a local variable, your UIView will dealloc when you do

[temp release];

because you have done nothing to increase the retain count since you alloced it.

For your string example...

[NSString stringWithString:@"Hello"];

returns an autoreleased string. if you will need to keep it for a very long time, you'll want to put a retain on it.

The second string example is a statically allocated string, and you do not have to worry about it. retain counts don't apply to them.

Stefan H
  • 6,635
  • 4
  • 24
  • 35
  • myView is not using a dot and, thus, doesn't matter if it is a property or not as direct assignment will not trigger a retain. – bbum Jan 19 '11 at 16:22
  • Re the "useful thing"--I strongly DON'T recommend tracking actual retain counts. Those numbers will change frequently for reasons that have little to do with what's happening in your code (upstream things in the framework, adding and removing objects, etc, etc) and you'll be totally confused and befuddled. The whole point of retain count memory management is that you can declare YOUR concerns, and not have to worry about what other pieces of the framework are acting on the object in question. – Dan Ray Jan 19 '11 at 16:38
  • For diagnostic purposes it works great. I don't mean to ship it in production code. But for testing chunks of code like that, and to see how retains counts get incremented and decremented, it works really well. – Stefan H Jan 19 '11 at 17:02
  • For diagnostic purposes, `retainCount` sucks. The only time it "works great" is in objects that never pass through system API of any kind. As well, one instance of `retain/autorelease` and the number is meaningless. There is always a better tool for tracking object lifespan and ownership. – bbum Jan 19 '11 at 17:39