Of course, if threads are the culprit then things are going to be entirely more complicated as it's possible for the variable to be sent -release at points between method invocations - are you using threads yourself explicitly (i.e. not spawned by the system frameworks)?
2) Actually, retaining them for use beyond the scope of the method is the reverse of what you'd want to do and would make managing memory very difficult indeed. You want to send -retain when you need an object and -release when you are finished with it. If you were to [link retain] in this method and never [link release] you'd have a leak. But yes, generally, you should retain any object that's being passed into a method to ensure that it stays around for the lifetime of that method and release them when you exit. In some cases, you can guarantee that the object won't receive a -release (for instance, when you're explicitly locking to guarantee that the code happens sequentially) but even then it is more of an optimization that is quite likely to break if your code is restructured than anything else. However, at this point, I wouldn't worry about optimizations such as that. There are better things to optimize than message passing overhead.
-rob. On Dec 26, 2008, at 2:49 AM, Scott Wilson wrote:
Okay, but just to be absolutely clear (so I can be sure I'm understanding this correctly):1) desiredURL is a local to my method. It is not used outside the method's scope.2) I get the exception within my method, not anywhere afterwards. I didn't think you had to retain objects passed as arguments into a method unless you wanted to use them beyond that scope. (That would certainly make things more complicated than I'd thought!)Am I missing something? Thanks! S.Indeed, you have no way of guaranteeing that link still exists as you are not explicitly claiming ownership to it. In the first case of your if, you receive an autoreleased NSURL instance (a new object created by using the contents of the link object). In the second, all your code is doing is deciding that desiredURL should point to the same object as link without claiming ownership of it. To ensure that you hold ownership of it, you need to explicitly retain it (code executing in the context of another thread might release it and cause it to receive -dealloc) or copy it (the former probably being the more appropriate in this case). Following that, it should be released when it is no longer of any relevance in this particular context.Therefor, I think you'll find that your findings are indeed the expected behavior - if it's worked in the past it's due more to luck than to anything else.-rob. On Dec 25, 2008, at 2:30 PM, Scott Wilson wrote:I have an odd case. I've got a NSTextView delegate method which looks like this:- (BOOL) textView: (NSTextView *) textView clickedOnLink: (id) link atIndex: (unsigned) charIndex { ... NSURL *desiredURL; // is it a NSURL link or a NSString link? if ([link isKindOfClass: [NSString class]]) { ...desiredURL = [NSURL URLWithString: [link stringByAddingPercentEscapesUsingEncoding: NSUTF8StringEncoding] relativeToURL: lastOpened];} else if ([link isKindOfClass: [NSURL class]]) // this is the case which causes the problem!!{ desiredURL = link; // it's a regular file:// URL } else return NO;NSLog(@"url %@", [desiredURL path]); // get EXC_BAD_ACCESS if link was an NSURL... }If I change the code above to desiredURL = [link retain] everything is fine. I've used very similar code with no problems in a different context.Is it possible that link is being autoreleased before my method has returned?Thanks _______________________________________________ Cocoa-dev mailing list (em...@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: http://lists.apple.com/mailman/options/cocoa-dev/em...@hidden This email sent to em...@hidden_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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/rob%40pinchmedia.com This email sent to r...@pinchmedia.com
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
