Goal c - reference counting

Question

Until five minutes, I was sure that my understanding of Objective c reference counting was excellent, but when I started checking keepCount objects, I was very surprised to see what I saw.

For example, myViewController has a UITableview:

.h file

@interface RegularChatViewController : UIViewController <UITableViewDataSource, UITableViewDelegate> { UITableView *_tableView; } @property (nonatomic, retain) IBOutlet UITableView *tableView; 

.m file

 @synthesize tableView = _tableView; - (void)loadView { _tableView = [[UITableView alloc] init]; // STEP ONE NSLog(@"tableView retain count: %d",[_tableView retainCount]); self.tableView.frame = CGRectMake(0, 0, 320, tableHeight); // STEP TWO NSLog(@"tableView retain count: %d",[_tableView retainCount]); [self.view addSubview:self.tableView]; // STEP THREE NSLog(@"tableView retain count: %d",[_tableView retainCount]); } 

To my surprise, the entrance was:

 tableView retain count: 1 tableView retain count: 2 tableView retain count: 3 

obviously STEP ONE increment counter by 1 using alloc

I also know that STEP THREE will increment the counter by 1 using addSubview

But what happens in STEP TWO ??? why did it increase the number of deductions?
is there anything in common with ARC ??

Answer 1

According to Apple docs in NSObject Protocol Reference for retainCount :

Important This method usually does not matter when debugging memory management issues. Since any number of infrastructure objects can store an object for storing links to it, while autocomplete pools can contain any number of pending releases on an object, it is very unlikely that you can get useful information from this method.

Answer 2

Once you interact with any method or framework function, the retainCount method becomes completely useless because you don’t know what these things do in their black boxes (they can add your objects to autocompletion pools or something else), and you don’t must take care of this.

Using retainCount to debug memory management issues is a bad idea. See this answer for even more reasons to avoid this.

Answer 3

I have a handy reference here: When to use saveCount?

In short, preserveCount rarely means what you think. Without knowing how UITableView and UIView , you cannot know what retention should be. And we don’t even take into account auto rating ...

Answer 4

Good in step two: - using self. tableView, the getter of the tableview property (which will be saved) will be called. Since your property is distributed and stored, both values ​​increase accordingly.

Whenever you have to allocate a stored property, you must overwrite its getter method, and this is called a lazy instance.

Better assign your table view to its recipient, for example.

 -(UITableView *) tableView { if(!_tableView) { _tableView = [[UITableView alloc]init]; } return _tableView; } 

Answer 5

self.tableView.frame will retain and autorelease when returning a tableView from the receiver.