On Thu, 17 Jul 2014 20:01:09 -0700, Jens Alfke said:
>Every once in a while I run into a bug in my code that’s triggered by
>self getting dealloced in the middle of a method. It’s usually something like
> - (void) someMethod {
> doSomeStuff;
> [self.delegate objec
And of course the second I hit Send I realized the do {} idea doesn't work.
Imagine if it was some variable other than self that you might *deliberately*
use to indicate when the loop should terminate.
--Andy
--Andy
> On Jul 18, 2014, at 10:07 AM, Andy Lee wrote:
>
> You could even eliminat
You could even eliminate the (admittedly negligible) cost of setting keepAlive
= nil by changing the if(keepAlive) to if(!keepAlive).
Along the lines of avoiding a message send, I wonder if this would work:
do {
// ...
} while (!self);
--Andy
> On Jul 18, 2014, at 9:41 AM, Gerd Knops wrot
That's similar to what I have used. Initially it started out simply as
id keepAlive=self;
...
keepAlive=nil;
but a few Xcode versions ago the static analyzer started complaining that it
wasn't really doing anything. So that last line became
if(keepAlive) { k
Do you know this code will always run on the main thread? Because you could
fix this from the other side, in the delegate. Use
dispatch_async(dispatch_get_main_queue(), ...) to un-assign the property.
But this won't work if you're on a non-main thread when you call back into
the delegate.
On Thu,
On Jul 17, 2014, at 11:01 PM, Jens Alfke wrote:
> Once I’ve identified such a bug, the fix is easy: put a [[self retain]
> autorelease] at the top of the method. Except now I’m using ARC, and I can’t
> find a simple way of doing it. I tried adding
> __unused id retainedSelf = self;
> but t
On Jul 17, 2014, at 11:01 PM, Jens Alfke wrote:
> Every once in a while I run into a bug in my code that’s triggered by self
> getting dealloced in the middle of a method. It’s usually something like
> - (void) someMethod {
> doSomeStuff;
> [self.delegate objec
On Jul 17, 2014, at 8:40 PM, Roland King wrote:
> Using the objc_precise_lifetime attribute ensures the object stays alice to
> the end of the block.
>
> I think that's a bit better than abusing retain release.
I'm not sure if that is reliable. It's possible that the optimizer sees that
the
Using the objc_precise_lifetime attribute ensures the object stays alice to the
end of the block.
I think that's a bit better than abusing retain release.
> On 18 Jul, 2014, at 11:23, Quincey Morris
> wrote:
>
>> On Jul 17, 2014, at 20:01 , Jens Alfke wrote:
>>
>> The only thing I’ve foun
On Jul 17, 2014, at 20:01 , Jens Alfke wrote:
> The only thing I’ve found that works is
> CFRetain((__bridge CFTypeRef)self);
> at the top of the method, and a corresponding CFRelease at the end, but this
> is pretty ugly
This seems to be the right way to do it. A CFBridgingRetain/CFBridg
Every once in a while I run into a bug in my code that’s triggered by self
getting dealloced in the middle of a method. It’s usually something like
- (void) someMethod {
doSomeStuff;
[self.delegate object: self didSomeStuff: yeah];
doSomeMore
11 matches
Mail list logo
