需要在iPhone内存管理中进行说明

Question

I need few clarification in iPhone memory management.

Here is an example for setters;
1).

-(void)setValue:(NSString*)input{
[value autorelease];
value = [input retain];
}

In this example, why we have to use autorelease? Can we use like as follows?

if(value)
[value release];
value = [input retain];

In the first example, Why we should not release the memory for input
2). If I use following statement; what is the retain count for value

NSString *value;
value = @"welcome";

After the above statement, just I am trying to set one more value. Then what will happen?

eg:
value = @"For testing";

3). What is the different between 2) and 3)?

NSString *value;
value = [input1 retain];
...
...
value = [input2 retain];// Now what is the retain count for 

4). If I use following statement, why the app is getting crash?

NSString *value = [[[NSString alloc] init] autorelease];
...
...

Thanks in advance..

Answer 1

If "input" is the exact same object as "value" then calling [value release] could dealloc the object. So you must retain the new input value, release the old value, then assign the new value to the ivar:

[input retain];
[value release];
value = input;

After each of 2) and 3), the NSString *value points to a literal NSString object, the retain count will be 1 in each case, and releasing it is probably not a good idea

After this code:

value = [input2 retain];

value is an alias to the input2 object. The thing to realize is that objects have retain counts, variables do not.

As for your last case,

NSString *value = [[[NSString alloc] init] autorelease];

It creates an autoreleased empty string. If you reference that object again once the autorelease actually happens, you may get a crash because you'll be referring to an object that doesn't exist any more.

Answer 2

If you release a value before you retain the new value then you can have problems if the same value is being set twice. This happens if the caller hasn't retained their own copy, such as when they get the value from the same object they try to set it on, like this:

object.value = object.value;

That statement will cause the object to be released before it's retained again which could lead to the memory being deallocated and result in a dangling pointer being retained. By doing the autorelease it ensures that copying the same pointer onto itself will work correctly.

Answer 3

1) You will have to do autorelease because of the following: When input is the same object as value and you will release value it's retain count will reach zero and get deallocated before you can retain it again though the input. You can do it with retain but you have to change your code:

-(void)setValue:(NSString*)input{
   if (value != input) {
      [value autorelease];
      value = [input retain];
   }
}

2) I believe @"Text" will be treated as a constant. When you want a object which you do not want any memory management with use:

NSString *value = [NSString stringWithString:@"Text"];

This will return an autoreleased object.

3) In this example it is not about the retain count of value, but about the retain count of both objects where value one is referenced to. When you dont release input1 before you leave that method, you will have a memory management problem.

4) This statement should work. No points to argue. You rather use [NSString string].

Note: For memory management: when you use alloc new or copy , you also have to use release or autorelease on the same object in the same scope.

Answer 4

I usually write my setters as

- (void)setValue:(NString *)input {
    if (value != input) {
        [value release];
        value = [input retain];
    }
}

which avoids the problem of input and value both being the same object. If you just release it without checking then you might completely free it and the next line will try to retain an object that doesn't exist anymore.

---

However, it's best practice to copy strings instead of retaining them :)

Answer 5

(assuming you're working in a non-gc env)

1) you can create a temporary variable and release the temp after the retain/assign. otherwise, you'd need to compare the pointers. deferred release may also mask threading errors (whether you consider that good or bad is...)

2) technically, the NSString literals are valid for the life of your program. that is: while (1) [@"why won't i die?" release]; while (1) [@"why won't i die?" release]; yields an infinite loop.

3) with explicit retain, alloc+init, new, and copy, you must counterbalance the retain count using release or autorelease. since you did not release value1, the static analysis may (correctly) spot that as a leak. since the string constants never die, the two aren't comparable in this regard.

4) there's nothing wrong with that staement. the problem lies elsewhere in your program. either you are assigning it to an ivar without retaining, or releasing it later.

try using static analysis often, and try reducing how much you use autorelease (you can't avoid it entirely).

none of this is magic, but you can at least reduce the location of many problems to the callsites (or very close) by not using autorelease all over the place. just use manual retain/release where possible.

lastly, check for leaks and run with NSZombies enabled.