Re: NSOperation and NSAutoreleasePool
Re: NSOperation and NSAutoreleasePool
- Subject: Re: NSOperation and NSAutoreleasePool
- From: Roland King <email@hidden>
- Date: Sat, 07 Mar 2009 19:18:22 +0800
On Mar 7, 2009, at 2:18 PM, Aaron Wallis wrote:
The property was assigned as:
@property (retain) id delegate;
when I walk through the code (and log pretty much everything out)
I get the following:
- (void)processString:(NSString *)tString withDelegate:(id)tDelegate {
NSLog(@"1. %@", tDelegate); // I get <TMPSTProcessDropOperation:
0x175930>
self.delegate = tDelegate;
NSLog(@"2. %@", self.delegate); // I get <NSAutoreleasePool: 0x187e10>
[self.delegate doSomething]; // I get -[NSAutoreleasePool
doSomething]: unrecognized selector sent to instance 0x187e10
}
and you are @synthesize-ing this property? There are no warnings in
your code about redeclaring variables or not synthesizing methods?
You're not inheriting from something else which declares a delegate?
Have you written a -(void)setDelegate:(id)delegate method, because if
you have that's what self.delegate is calling, that line of code is
identical to [ self setDelegate:tDelegate ]. If you have for some
reason written that method, even if you synthesize the property,
synthesize will not overwrite it.
What's bizarre here is that what is ending up in self.delegate is an
object with an entirely different address. I could believe that you
have an overreleased object and the memory was being reused and it
*looked* like an autorelease pool, but it's just not the same pointer
at all. You are telling it above, set self.delegate to the object at
0x175930 and yet what ends up in delegate is the object at 0x187e10.
That's why I ask if you have a -(void)setDelegate: method which is
broken and not actually setting the delegate to the argument you
passed in.
What happens if you single step INTO that self.delegate = tDelegate
method? If it's synthesize I think the debugger just moves to the
@synthesize line for one or two steps, you don't actually see any
code, if you have another setDelegate: method you're calling, it
should go there and you'll see what's going on. Also, what is
self.delegate set to before set it to tDelegate?
Note that all the other comments about setting a delegate once and not
retaining it are very valid and true. Its not a hard and fast rule the
delegates are unretained, but in many cases if delegate means what it
usually means, you end up with a retain cycle if you retain them.
Your solution, setting the delegate member variable directly, sort of
breaks your own encapsulation. That's exactly what self.delegate =
tDelegate should do. Focus on that line of code and figure out what it
doesn't do it.
_______________________________________________
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