Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
- Subject: Re: Releasing ivars in -didTurnIntoFault. Should set to nil?
- From: Quincey Morris <email@hidden>
- Date: Thu, 13 Aug 2009 14:30:54 -0700
On Aug 13, 2009, at 13:33, Georg C. Brückmann wrote:
Well, is there any disadvantage when autoreleasing? (I’m not talking
about tight loops here – that’s another topic.) Generally speaking,
releasing a delegating object, when it notifies its delegate that
it’s finished, should be fine from the delegate’s point of view.
Also, I’m interested what method of reference releasing you’d
recommend, because the timer issue mentioned above would be equally
present when releasing instead of autoreleasing.
Note that I don’t want to persuade you, I just don’t see any
disadvantage of autoreleasing while I do see a slight advantage.
We're in a thread where the opinion has been expressed (I'm
paraphrasing here, not quoting) that it's a bit safer to set a
reference to nil (as opposed to leaving it pointing to a possibly non-
existent object) just after releasing it. There's more to that
opinion, but that's the guts of it, and I agree with it.
Your refinement was to suggest that it's even safer to autorelease the
reference, instead of releasing it, before setting it to nil. My point
was that it's not safer as a general principle -- it's just a solution
to what would otherwise be a lifetime-maintenance bug in your code, in
a specific scenario.
So what's the disadvantage to doing it generally? Well, ...
1. [not important] It clutters up the autorelease pool unnecessarily.
2. [somewhat important] It instills a false sense of security, but
implying that extending the object lifetime to the next pool drain is
always a sufficient lifetime extension. It isn't, not necessarily.
3. [somewhat more important] If you switch to garbage collection,
solving the original problem (in the NSURLConnection case) with
autorelease isn't possible. Under GC, the "defect" (if you'll excuse
the word) in your original design is revealed, and finding a solution
may be considerably more difficult.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden