> Unfortunately, this contract isn't always followed. Lots of people
> "optimise" away this policy instead of doing a "superfluous" 'return
> [[foo retain] autorelease]'.
On initial read, I didn't quite follow this. If my method is returning a foo
that I know I have "retained", what requirement is there on me to bump the
retain count temporarily?
Even if I have an object whose "nominal" retain count is zero (ie, its going to
disappear on the next autorelease-pool-drain), surely the "superfluous" [[foo
retain] autorelease] only gives it a life while its "in the stack frame", which
is to say nothing extra. Its not my problem if the guy who called me has his
own pool that will be free'd when he returns?
But then I saw the case where I have an object which returns, as a method
result or a property, one of its instance variables. The caller holds on to it
(without retaining it) then releases (and deallocs) my object. My object
releases its instance variables which results in the caller holding a reference
to a dead value.
{
Object *o = [Object new];
NSString *s = o.somevalue; // gets o's instance variable (without
retain)
[o release]; // o's instance variable is released
NSLog(@"Crash: %@",s) // accesses dead string
}
So, yes, the retain/autorelease isn't superfluous at all, though the usage
pattern that would trigger the problem seems relatively unlikely (in my
example, o seems far more likely to be autorelease'd). Is there a more common
case that I'm missing?
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
