Let's say I want to create a temporary variable, e.g.:
To point to another long-living variable:
__unsafe_unretained UIView *tableHeaderView = self.tableView.tableHeaderView;
To point to an object I just created.
__unsafe_unretained UIView *tableHeaderView = [[UIView alloc] init];
These temporary variables don't need to be retained because the objects they point to are guaranteed to keep positive retain counts for as long as the temporary variables are in scope. So, should I declare them as __unsafe_unretained?
Why does it matter if the system retains your temp variable? And as a matter of fact, you DO want to retain it.
Consider:
__unsafe_unretained UIView *tableHeaderView = self.tableView.tableHeaderView
self.tableView.tableHeaderView = nil;
NSLog(#"%#", tableHeaderView); //<-I WILL CRASH
Matt,
The whole point of ARC is to let you ignore these kinds of issues. In fact, the complier may not even retain these instances.
Let ARC worry about these issues. Don't try to help it until the compiler or the static analyzer complain. (BTW, you are letting the analyzer run with every compile, right? It finds problems as you create them.)
You should only worry about excess object creation in loops and managing the creation of large objects. The former is handled by judicious use of #autorelease. You still manage large items as you did ante-ARC.
Andrew
No. If ARC retains it, it will let go when the variable goes out of scope.
Related
Here's my current situation:
I have a NSMutableArray named dictKeyArray which I assign a property with #property(nonatomic,retain)NSMutableArray *dictKeyArray
I synthesize my mutable array in the implementation file.
Later, I have a dictionary name storeDict. I assign all the keys of the dictionary to the dictKeyArray like so:
dictKeyArray = [[storeDict allKeys] mutableCopy];
Now I use this dictionary later in my implementation file. However, when it comes to releasing it, I release it once in my dealloc method. When checking with instruments, a leak shows up! Why is dictKeyArray leaking? Should I be using assign instead of retain?
I'm still not clear on what the difference is exactly...
thank you!
You have to send it an
[[[storeDict allKeys] mutableCopy] autorelease];
Just to make this clear: mutableCopy does the same as alloc meaning you are claiming ownership of the object in question. You have to decrease the retainCount by one.
By the way: You should use the accessor you wrote for it. You are just assigning it to your iVar at the moment. If you want to make your accessors work, you will have to use something like
object.dictKeyArray = ...;
in general. Or here (as mentioned by dreamlax)
self.dictKeyArray = ...;
because you are referring to an object of this specific class the code is in.
Only this way you are ensuring your object is properly retained by your accessor. Otherwise writing the accessor code doesn't make sense at all because it never gets called.
Please note: As Josh said in the comments, your code should be valid (at least from my point of view). What I suggested is a solution that is not as error-prone as yours because you adhere to the rules (could save you from headache in the near future).
You should be using self.dictKeyArray = .... Without the self. you are accessing the instance variable directly, bypassing any memory management benefits of properties, but, remember that you own the result of mutableCopy, and assigning to a property that also takes ownership will result in double-ownership, so use:
self.dictKeyArray = [[[storeDict allKeys] mutableCopy] autorelease];
Under ARC, a block is suspected to cause a retain cycle if you're using self inside the block, for example.
I've seen a workaround here, like this:
How can this workaround prevent a retain cycle?
weakRequest is just a pointer to the exact same object referenced by request. When ARC modifies the retain count of weakRequest or request, it's affecting the same object.
Then, in the block, there is this strange thing going on:
__strong ASIHTTPRequest *strongRequest = weakRequest;
This is the eqivalent to saying:
ASIHTTPRequest *strongRequest = weakRequest;
[strongRequest retain];
But again: It's one and the same object. Why all these different variable names? They're just pointers!
I never really cared much about blocks and tried to avoid them. But now this made me curious about what everyone is talking about when they say "a block captures the variables". Until today I thought this just means a block will retain every pointer you use which has been defined outside of the scope of the block, meaning that the block just retains whatever object you touch in it's scope.
I did this quick test:
UIView *v = [[UIView alloc] initWithFrame:CGRectMake(100, 100, 100, 100)];
[self.view addSubview:v];
v.backgroundColor = [UIColor orangeColor];
NSLog(#"self = %p", self); // 0x6a12a40
[UIView animateWithDuration:1.5
delay:0
options:UIViewAnimationOptionAllowUserInteraction
animations:^{
UIViewController *my = self;
NSLog(#"my = %p", my); // 0x6a12a40
v.frame = CGRectMake(200, 200, 100, 100);
}
completion:nil];
Like you can see the object itself stays exactly the same. The block does not create a copy. So I can safely assume all the years of C and Objective-C knowledge are still valid:
ASIHTTPRequest *strongRequest = internetRequest;
ASIHTTPRequest *foo = strongRequest;
ASIHTTPRequest *bar = foo;
if (bar == internetRequest) {
NSLog(#"exact same thing, of course");
}
So what is going on there? How can this resolve a retain count if all that's happening is create different pointers to the same object? Why the extra mile of creating those pointers?
Wouldn't this be totally the same thing?
[request setCompletionBlock:^{
NSString *respondeString = [request responseString];
if ([_delegate respondsToSelector:#selector(pingSuccessful:)]) {
[_delegate pingSuccessful:responseString];
}
}];
There must be some secret about Objective-C which explains why duplicating pointers solves memory management problems here. It just doesn't make any sense to me.
It actually has nothing to do with ARC, but rather how blocks capture variables. The pointer is duplicated so that the variable captured by the block has the correct ownership qualifier.
weakRequest is just a pointer to the exact same object referenced by request. When ARC modifies the retain count of weakRequest or request, it's affecting the same object.
Right, they both point to the same object, but weakRequest has the __unsafe_unretained ownership qualifier, which means that when that variable is captured by the block, its retain count is unchanged.
If request were captured by the block then it would be retained and you would have retain cycle, regardless of whether you're using ARC.
The conversion back to a __strong pointer simply keeps that object alive for the duration that block execution.
Well, you specify a variable as __weak precisely so that the block won't retain it so that you can avoid a retain cycle. However, creating a __strong Variable inside the block and pointing it to the __weak variable is completely superfluous. You designate it as weak so that the block won't retain it. Creating a new one and designating it as __strong doesn't mean anything because there's no instance whereby the block will need to retain it. __strong is only a compiler keyword to tell ARC to retain the value if the need arrives...and ARC will never find that need since it's already been passed into the block. In the end, you could simply use the weakRequest variable and do away with the strongRequest variable.
You may be confused because there are two different things going on, to prevent two different problems. You quoted this line:
__strong ASIHTTPRequest *strongRequest = weakRequest;
That line does not prevent a retain cycle.
The (potential) retain cycle is one problem. The retain cycle would contain three objects: self, the ASIHTTPRequest, and the block. Use of the weakRequest variable breaks that cycle, because the block captures the weakRequest, which does not own the ASIHTTPRequest object. In reference count terms, assigning te weakRequest does not increment the reference count of the ASIHTTPRequest.
The line you quoted is there to prevent the other problem, which is created by solving the first problem. The other problem is a potential dangling pointer. Since weakRequest doesn't own the ASIHTTPRequest, there's a risk that during the execution of the completion block, all owners of the ASIHTTPRequest will release it. Then weakRequest will be a dangling pointer - a pointer to an object that has been deallocated. Any use of it is likely to cause a crash or heap corruption.
In the line you quoted, the block copies weakRequest to strongRequest. Because strongRequest is __strong, the compiler generates code to retain (increment the reference count of) the ASIHTTPRequest, and code to release it at the end of the block. This means that even if all other owners of the ASIHTTPRequest release it while the block is running, the ASIHTTPRequest will stay alive because the block has temporarily made itself an owner of the request.
Note that this solution to the dangling pointer problem is not thread-safe. If the owners of the request can release it from other threads while block is executing, there is a race condition that can still lead to a dangling pointer. This is why you should try to use __weak instead of __unsafe_unretained for weak pointers: __weak references can be copied to __strong references without a race condition.
I have been working with Objective-C for a month approximately but regretfully I'm still a complete dummy in memory management so I need your advice. I pass an array from one file to the other like this
BidView *bidView = [[[BidView alloc] init] autorelease];
NSLog(#"%i",[bidView.seatsForTableCreated retainCount]);
bidView.seatsForTableCreated = [NSArray arrayWithArray:seats];
NSLog(#"%i",[bidView.seatsForTableCreated retainCount]);
[self.navigationController pushViewController:bidView animated:YES]; `
NSLog tells me that retain count of seatsForTableCreated has raised from zero to two. Then, when I quit the BidView screen (without doing anything with seatsForTableCreated array) I' m doing the following:
NSLog(#"%i",[seatsForTableCreated retainCount]);
[seatsForTableCreated release];
NSLog(#"%i",[seatsForTableCreated retainCount]);
it's quite unclear for me. Now NSLog tells me (both times) that retain count is 1. Then I repeat this procedure (running the same application I mean) and each time things are the same:0-2-1-1. So my questions are:
1)Why 0 to 2? Why retain count increases to 2 not to 1?
2)why then it drops to 1 without being impacted in any way?
3)Why it still remains 1 after i've released it?
4)How would you manage the memory in such a case?
Great thanks in advance
First and foremost. Don't call nor use retainCount for nothing, think about this property as private and only the OS can call. To check if you have a memory leak you should use Instruments.
Seems like you've created an autoreleasing ([NSArray arrayWithArray:seats]) object, so you can't manually release it.
And use the Allocations Instrument to really check if you have a memory leak.
My advice assumes you are using Xcode 4+ and you are not using ARC,
command+shift+B will analyse your memory management (and dead stores and such). I think you got it right. Don't worry about the retain counts so much until you get a complaint from Analyze or find leaks with Instruments. I am not sure how reliable retain counts are. I have seen comments on SO saying not to rely on them.
You are following the rules well
New, Alloc, Copy, Retain --> You will need to release this object when you are done with it.
I am also assuming in BidView.h your property is declared as
#property(nonatomic, retain) NSArray * seatsForTableCreated;
So releasing that in the dealloc method in BidView.m is good memory management
EDIT
It works when even though you don't allocate seats for table created because.
self.seatsForTableCreated = ... will retain whatever object you are setting there.
So if you have a property with (retain) in the declaration, you can consider
self.property = object;
as setting property and retaining it. The properties were added to objective-C to reduce similar code being in every class.
A property in .h
#property (nonatomic,retain) NSObject * property; // don't name your properties property..
Compiler will create 2 methods for you automatically when you #synthesize in the .m
-(void)setProperty:(NSObject*)newP
{
[newP retain]; // retains the new object so it sticks around for line 3
[property release]; // releases previous property
property = newP; // set the property to the object retained in line 1
// property is now same as newP and you are responsible for releasing it
// -(void) dealloc is where you should release it
}
// Note, the compiler may not create the exact same code as above when creating the //setProperty method. If it does, it could be subject to change.
-(NSObject*)property
{
return property;
}
I tried to figure out why Analyze isn't catching the issue when you don't release your property, but haven't. That is confusing and I want to explore it further.
I've run into some unfamiliar Objective-c memory management code. What is the difference between:
// no property declared for myMemberVariable in interface
id oldID = myMemberVariable;
myMemberVariable = [MyMemberVariable alloc] init];
[oldID release];
and:
// (nonatomic, retain) property is declared for myMemberVariable in interface
self.myMemberVariable = [[MyMemberVariable alloc] init];
Thanks!
The second is technically incorrect, but the first probably stems from someone yet to embrace Objective-C 2.0 property syntax. It was added relatively recently if you're a long-time OS X developer (or an even-longer-time NextStep/OS X developer), so you do see people not using it without gaining any benefit or detriment by not doing so.
So the first is basically the same as:
[myMemberVariable release];
myMemberVariable = [[MyMemberVariable alloc] init];
Given that you have a 'retain' property, the correct version with the setter should be:
// this'll be retained by the setter, so we don't want to own what we pass in
self.myMemberVariable = [[[MyMemberVariable alloc] init] autorelease];
In the first example, you've got an instance variable. In the second, a property with auto memory management attributes (as indicated by the retain).
In the first example, you're allocating an object, assigning it to an instance variable, then releasing it. It also appears that you're also leaking the object that was previously assigned to it since you don't explicitly release it. (Maybe it's autoreleased, can't tell here).
In the second example, you're allocating an object, and assigning it to a property that is retaining it. This means you're going to leak it unless you explicitly release/autorelease it.
self.myMemberVariable = [[[MyMemberVariable alloc] init] autorelease];
or
MyMemberVariable *m = [[MyMemberVariable alloc] init];
self.myMemberVariable = m;
[m release];
It's much better to use properties as you get (most) memory management for free. For example, you won't have to worry about freeing a reference before assigning a new one.
The first form does not use properties. I don't see a good reason not to do:
[myMemberVariable release];
myMemberVariable = [[MyClass alloc] init];
Since the old value is definitely not the same as the new one, so there is no chance any old value is released before it can be retained again.
Properties have the advantage that, in newer compilers, they are synthesized by the compiler and simply do the right thing, i.e. they know how to retain the new and release the old value, if the type is one that must be retained or copied. This is not necessary for types like int, float, etc., since these are simple value types.
In other words, if you use dot notation, either on self or on some other object, you access the property and in fact call either the getter or setter methods, depending on the direction of assignment.
If you access the ivar (member variable) directly, you don't have the protection from the property and have to code retain/release yourself.
You can also write your own setters and getters, and then you'll also have to take care of memory management, where it applies. It does, however, give you more flexibility. You could log items, check the validity of the input, update internal state variables, etc.
What is the difference between the following 2 ways to allocate and init an object?
AController *tempAController = [[AController alloc] init];
self.aController = tempAController;
[tempAController release];
and
self.aController= [[AController alloc] init];
Most of the apple example use the first method. Why would you allocate, init and object and then release immediately?
Every object has a reference count. When it goes to 0, the object is deallocated.
Assuming the property was declared as #property (retain):
Your first example, line by line:
The object is created by alloc, it has a reference count of 1.
The object is handed over to self's setAController: method, which sends it a retain message (because the method doesn't know where the object is coming from), incrementing its reference count to 2.
The calling code no longer needs the object itself, so it calls release, decrementing the reference count to 1.
Your second example basically does steps 1 and 2 but not 3, so at the end the object's reference count is 2.
The rule is that if you create an object, you are responsible for releasing it when you're done with it. In your example, the code is done with tempAController after it sets the property. It is the setter method's responsibility to call retain if it needs that object to stick around.
It's important to remember that self.property = foo; in Objective-C is really just shorthand for [self setProperty:foo]; and that the setProperty: method is going to be retaining or copying objects as needed.
If the property was declared #property (copy), then the object would have been copied instead of retained. In the first example, the original object would be released right away; in the second example, the original object's reference count would be 1 even though it should be 0. So you would still want to write your code the same way.
If the property was declared #property (assign), then self isn't claiming ownership of the object, and somebody else needs to retain it. In this case, the first example would be incorrect. These sorts of properties are rare, usually only used for object delegates.
As others have noted, the two code snippets you show are not equivalent (for memory management reasons).
As to why the former is chosen over the latter:
The correct formulation of the latter would be
self.aController= [[[AController alloc] init] autorelease];
Compared with the former, this adds additional overhead through use of the autorelease pool, and in some circumstances will lead to the lifetime of the object being unnecessarily extended (until the autorelease pool is released) which will increase your application's memory footprint.
The other "possible" implementation (depending on where the example is from) is simply:
aController = [[AController alloc] init];
However, setting an instance variable directly is strongly discouraged anywhere other than in an init or dealloc method. Elsewhere you should always use accessor methods.
This brings us then to the implementation shown in sample code:
AController *tempAController = [[AController alloc] init];
self.aController = tempAController;
[tempAController release];
This follows best practice since:
It avoids autorelease;
It makes the memory management semantics immediately clear;
It uses an accessor method to set the instance variable.
Note also that your desire to cut the code down to one line is why many people use Autorelease:
self.aController = [[[AController alloc] init] autorelease];
Though in theory on the iPhone autorelease is somehow more expensive (never heard a clear explanation why) and thus you may want to explicitly release right after you assign the object elsewhere.
If you're using Xcode, it can help you detect such code with the static analyzer.
Just hit Build >> Build and Analyze
This will show you a very helpful message at such pieces of code.
One other thing to note is that your example depends on the #property definition of aController also.
If it were defined as #property (readwrite, retain) id aController; then your example works, while if it is defined as #property (readwrite, assign) id aController; then the extra call to release would cause your object to be deallocated.
You could also do
#property (nonatomic, retain)AController *aController;
...
self.aController= [[AController alloc] init];
[aController release];
with a retaining property, and it would function the same way, but its better to use the other way (for retaining properties) because it's less confusing, that code makes it look like you assign aController and then it gets deleted from memory, when actually it doesn't because setAController retains it.