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.
Yes, I think that’s the point the we’ve been paying most attention to.
3. [somewhat more
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
In fact, relinquishing ownership of the connection during this
method is simply a bug. If you're its owner, you're responsible for
preventing it from being deallocated while it's still alive -- and
it's still alive.
In this case, you're pretty sure that autoreleasing it keeps it from
bein
On Aug 13, 2009, at 03:45, Georg C. Brückmann wrote:
Consider NSURLConnection’s -connectionDidFinishLoading: delegate
method:
- (void)connectionDidFinishLoading:(NSURLConnection *)connection {
// Do stuff
[myReferenceToTheConnection release];
Quincey –
In practice, the delegate is often -- independently of its role as
delegate -- the *owner* of the referencing object (e.g. a window
controller that is a delegate of a table view loaded from a nib file
is the owner of the nib file's contents, including, directly or
indirectly, th
On Aug 12, 2009, at 15:00, Georg C. Brückmann wrote:
I agree with that point. You may want to declare a macro like this:
#define INVALIDATE_REFERENCE(obj) ([(obj) autorelease], (obj) = nil)
The reason I chose autorelease over release are situations like the
following: You register as a deleg
On 12.08.2009, at 22:59, Dave Keck wrote:
I've found that there's never any reason not to reset a variable after
releasing it. IMO it's just good practice.
I agree with that point. You may want to declare a macro like this:
#define INVALIDATE_REFERENCE(obj) ([(obj) autorelease], (obj) = nil)
>
> >Now I understand that if nilling an instance variable after releasing
> >it is done in -dealloc, it is papering over other memory management
> >problems and is therefore bad programming practice. But I believe
> >that this practice is OK in -didTurnIntoFault because, particularly
> >when Undo
On 8/12/09 11:41 AM, Jerry Krinock said:
>I release a "regular" instance variable in my managed object's -
>didTurnIntoFault, and discovered that this was causing a crash
>sometime after an undo. In searching code on the internet I see that
>others have reported such crashes. I solved the proble
I release a "regular" instance variable in my managed object's -
didTurnIntoFault, and discovered that this was causing a crash
sometime after an undo. In searching code on the internet I see that
others have reported such crashes. I solved the problem by setting
the instance variable to n
10 matches
Mail list logo
