views:

91

answers:

5

In Apple's example code, the method tableView:cellForRowAtIndexPath: of a UITableViewDataSource returns a cell with a retain count of 1; it allocs it, but doesn't autorelease it. However, the static analyzer complains that this violates the Cocoa naming conventions, since the method name doesn't start with 'new', etc. The documentation doesn't mention the expected retain count of the cell. What retain count should the cell have? Should I file a bug against the documentation? Thanks.

EDIT: The example code I looked at does autorelease it, and my eye somehow skipped over it. Sorry to waste your time. Thanks for the responses.

Further edit: A bug should probably be filed against Clang if questioners are going to get jumped for using its terminology in a question. :-)

+1  A: 

The value of retainCount is not really important (it can go up and down for seemingly unknown reasons). But cells created in tableView:cellForRowAtIndexPath: should be autoreleased. What example code are you looking at?

Brian
Clang SA uses "retain count of 1" to mean "owned by the current bit of stack", i.e. `[foo retain]` and `[[Foo alloc] init]` have retain counts of 1, while `[[foo retain] autorelease]` and `[[[Foo alloc] init] autorelease]` have retain counts of 0.
tc.
@tc. That's interesting -- but questionable terminology, perhaps.
walkytalky
That's right, just using Clang's terminology.
David M.
+1  A: 

Which example code? MyTableViewController.m returns either [tableView dequeueReusableCellWithIdentifier:kCellID] or [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:kCellID] autorelease].

If the example code does something different, it's probably wrong. Nearly all methods follow Objective-C naming conventions; the ones that don't tend to be explicitly documented.

tc.
A: 

Retain count is always at least 1. You won't ever get back an object with a retain count less than that, it would be an ex-object already. Please please please don't draw conclusions from retain counts, or have expectations about them, or even ever look at them. Never never never never never.

There may possibly be dodgy example code here and there that does the wrong thing. Ignore it. Do the right thing and don't fret yourself about the rest.

walkytalky
A: 

In fact, DO NOT USE THE retainCount at all. I got so confused and it lead me into the totally wrong direction and I wasted literally days hunting down wrong leaks. It means ABSOLUTELY NOTHING if the count goes up or down! Don't waste a second dealing with it.

It's much better to use the Leak or Zombie tools!

(ps also thanks to walkytalky - as I just see he also answered this one!)

A: 

Don't worry about the retain count. You alloc a UITableViewCell in your cellForRowAtIndexPath:, which means you have to release it or you have a memory leak. You can't release it because you have to return the cell, have the table view draw it as a subview, then release it. Therefore you autorelease it to have the autorelease pool release it later. When you return it, it hasn't been released yet, but gets released later by the system (you've simply relinquished ownership of it, which is what you want, because you don't maintain a reference to the cell after it's returned from the function).

anshuchimala