Re: ARC dealloc best pratice
On Feb 6, 2015, at 11:34:35, Kyle Sluder k...@ksluder.com wrote: Dealloc is too late for a lot of this stuff. I try to keep -dealloc as pure as possible; that is, -dealloc should only be concerned with memory management. Removing observers, unbinding, unregistering notifications, and timer invalidation all happens in -viewWillMoveToWindow: or another similar place. I'm curious where you put such housekeeping tasks for window controllers, if dealloc is the wrong place. Override close? Handle windowWillClose? -- Steve Mills Drummer, Mac geek ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Fri, 6 Feb 2015 12:46:44 -0800, Jens Alfke said: Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? The 'why' has been answered, but worse it's not even clear sometimes what a delegate's situation is. Take NSTableView.h in the 10.10 SDK: - /* Get and set the delegate. The delegate can implement methods in the protocol NSTableViewDelegate. All delegate methods are optional. The delegate is a weak reference (non retained) in non garbage collected applications. Under garbage collected apps, it is a strong reference. The default value is 'nil'. */ - (void)setDelegate:(id NSTableViewDelegate)delegate; - (id NSTableViewDelegate)delegate; - So based on Greg saying We prefer to reserve the term 'weak' for safe zeroing weak. I guess for NSTableView there's no need to nil the delegate. OTOH, my experience converting my GC app to ARC says the exact opposite. Without clearing the delegate to nil in say windowWillClose, I get sporadic crashes. What's the true situation for NSTableView? Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 10 Feb 2015, at 21:20, Sean McBride s...@rogue-research.com wrote: On Fri, 6 Feb 2015 12:46:44 -0800, Jens Alfke said: Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? The 'why' has been answered, but worse it's not even clear sometimes what a delegate's situation is. Take NSTableView.h in the 10.10 SDK: - /* Get and set the delegate. The delegate can implement methods in the protocol NSTableViewDelegate. All delegate methods are optional. The delegate is a weak reference (non retained) in non garbage collected applications. Under garbage collected apps, it is a strong reference. The default value is 'nil'. */ - (void)setDelegate:(id NSTableViewDelegate)delegate; - (id NSTableViewDelegate)delegate; - So based on Greg saying We prefer to reserve the term 'weak' for safe zeroing weak. I guess for NSTableView there's no need to nil the delegate. OTOH, my experience converting my GC app to ARC says the exact opposite. I think that what Greg means is that when used in the context of ARC weak is a synonym for zeroing weak. Weak is also used (as you have shown) in the AppKit documentation, and likely dates back to the introduction of GC which also used weak and strong modifiers. AppKit is not compiled using ARC so any ref to a weak reference cannot imply a zeroing weak reference. Without clearing the delegate to nil in say windowWillClose, I get sporadic crashes. I agree that zeroing out these unretained delegates remains a necessity. Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 6 Feb 2015, at 17:34, Kyle Sluder k...@ksluder.com wrote: On Fri, Feb 6, 2015, at 08:48 AM, Jonathan Mitchell wrote: So I want to have a best practice template to follow in my dealloc. Dealloc is too late for a lot of this stuff. I try to keep -dealloc as pure as possible; that is, -dealloc should only be concerned with memory management. Returning briefly to the core point to this thread. Sometimes, in order to access objects to be unobserved etc I may message self in my dealloc. Am I playing with matches in the woodshed? So, is the following correct under ARC in dealloc: 1. Dealloc is sent to each subclass prior to any manipulation of the retain state for its ivars. 2. The object graph is still intact during dealloc and may be safely navigated (assuming that I don’t zero out any references myself in dealloc). 3. What is not okay is to call any code path in dealloc that would cause self to be stored into a pointer that is subsequently dereferenced. 4. It is okay to call a code path that would cause an ivar/property to receive an additional strong reference (i.e.: the dealloc code causes an ivar that would otherwise have been deallocated to be retained) I have no problem in recognising that it is trivially easy to screw things up in dealloc but it would help to know the boundaries a bit more clearly. I think someone mentioned that dealloc was covered in some detail in a WWDC 2011 session but I haven’t been able to pin down just which one yet. Thanks Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
Here's where I am confused. I thought you were running into problems on the Mac, but I see you mention iOS 5.1 and 6.0 while you mention that you are running into problems with NSViewController. If you were running into problems on iOS, I'd expect to see UIViewController, not NSViewController. Do you mean UIViewController and iOS or are these Mac OS issues? Thanks, Alex Sent from my iPad. Please pardon typos. On Feb 6, 2015, at 2:55 PM, Jonathan Mitchell jonat...@mugginsoft.com wrote: On 6 Feb 2015, at 17:34, Jens Alfke j...@mooseyard.com wrote: On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: // remove observers // unregister for notifications I have to confess I'm still not completely certain whether these are needed under ARC. I remember reading something about at least one of these being handled automatically, but I just skimmed through some docs now and couldn't find anything. I tend to put these in my classes but always wonder whether I strictly need to. I would say it is necessary. Warnings result otherwise and unremoved observers do seem to lead to instability. // set any non-weak delegates to nil (NSTableView et al) I think you meant set any _weak_ delegates to nil, i.e. clear the delegate property of any object of whom I'm the delegate. Non-weak doesn't make sense, because if a delegate has a strong reference to self, then self can't possibly be in its dealloc method. Sorry. I wasn’t clear enough probably. Most of my issues centre around NSViewController. Say I have an outlet to an NSTableView and the tableView.delegate = self. The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is unsafe_unretained I believe self can be deallocated leaving tableView.delegate as a dangling pointer. Note that this is only necessary if (a) the other object can outlive self, and (b) the other object could still send the delegate messages in the future. The problem is that there is, I believe, no way to accurately determine whether a or b is true in any particular instance! Recently I have resolved issues where both NSTableView and WebView were sending delegate messages and responder chain actions in situations that I hadn’t expected. A stone dead app is the result. Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com This email sent to z...@mac.com ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 6 Feb 2015, at 17:34, Kyle Sluder k...@ksluder.com wrote: Dealloc is too late for a lot of this stuff. I try to keep -dealloc as pure as possible; that is, -dealloc should only be concerned with memory management. I agree that dealloc is far from perfect. What it does have going for it is ubiquity and reliability. In also implement a -dispose method that I trigger from -windowWIllClose. This cascades down the view controller hierarchy but needs a bit of glue of course. Removing observers, unbinding, unregistering notifications, and timer invalidation all happens in -viewWillMoveToWindow: or another similar place. -viewWillMoveToWindow: can called a lot if a view is repeatedly added and removed from the window view hierarchy. It would also need hooked up to the view controller to be actually useful. To be honest the “other place” doesn’t generically exist in my experience. Hence -dealloc and -dispose. Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 12:46 PM, Jens Alfke j...@mooseyard.com wrote: On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is unsafe_unretained I believe self can be deallocated leaving tableView.delegate as a dangling pointer. This is still a weak reference, it's just unsafe (non-zeroing.) You're right that these need to be cleaned up manually. Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? Converting an unowned reference to a zeroing-weak reference can cause compatibility issues with existing applications that are not prepared for the additional semantics required by zeroing-weak references. While this isn’t a deal breaker for the future, there still needs to be a compatibility path for older applications, and the entire code base needs to be audited to ensure correct operation (either by conversion to ARC or ensuring that access goes through the proper gating functions). The problem is that there is, I believe, no way to accurately determine whether a or b is true in any particular instance! It depends on the class. For example, NSURLConnection has a well-defined order in which it sends delegate messages, so it's possible to know when it's not going to send any more messages. But yeah, in a window's view hierarchy it's extremely unpredictable so it's important to zero out delegate references. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com This email sent to david.dun...@apple.com -- David Duncan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is unsafe_unretained I believe self can be deallocated leaving tableView.delegate as a dangling pointer. This is still a weak reference, it's just unsafe (non-zeroing.) You're right that these need to be cleaned up manually. Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? The problem is that there is, I believe, no way to accurately determine whether a or b is true in any particular instance! It depends on the class. For example, NSURLConnection has a well-defined order in which it sends delegate messages, so it's possible to know when it's not going to send any more messages. But yeah, in a window's view hierarchy it's extremely unpredictable so it's important to zero out delegate references. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 6 Feb 2015, at 20:46, Jens Alfke j...@mooseyard.com wrote: Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? I presume that AppKIt (all of it?) is not compiled using ARC and hence doesn’t get weak reference tracking et al? Why isn AppKit compiled using ARC? Probably because it has a track record as it is and would likely gain nothing in a functional sense. ARC works as advertised in general usage but managing unsafe_unretained references is as delicate a business as it is when using manual ref counting. These sorts of difficulties are the inspiration of course for managed languages like C# which are largely free from these niceties. However Obj-C’s dalliance with GC didn’t work out too well and there were as many issues with -finalise as there are with -dealloc. Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 6 Feb 2015, at 21:31, Greg Parker gpar...@apple.com wrote: Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? Some classes are incompatible with (safe zeroing) weak references. For example, any class that implements custom retain count storage needs additional code to work with weak references. That means AppKit needs to be careful about binary compatibility when it changes an unretained delegate to a weak delegate. Does Swift avoid unsafe-unretained references entirely or does it rear its head when interacting with Obj-C? J ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 2:00 PM, Greg Parker gpar...@apple.com wrote: Swift adds unowned references. These references are non-retaining. They differ from weak references and unsafe unretained references: unowned references fail with a runtime error if you try to access the pointed-to object after it has been deallocated. … They are cheaper than weak references and safer than unsafe-unretained. What makes them cheaper than weak references? It sounds like they both have to do the same bookkeeping to track whether the pointed-to object is alive; the only difference is the behavior when accessing the reference after the pointed-to object is dealloced (i.e. treating the pointer as nil vs. failing with an error.) Both of those seem equivalent in complexity. But maybe I'm off-base on how weak references are implemented… I'd love to see an explanation, actually. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 1:48 PM, Jonathan Mitchell jonat...@mugginsoft.com wrote: On 6 Feb 2015, at 21:31, Greg Parker gpar...@apple.com wrote: Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? Some classes are incompatible with (safe zeroing) weak references. For example, any class that implements custom retain count storage needs additional code to work with weak references. That means AppKit needs to be careful about binary compatibility when it changes an unretained delegate to a weak delegate. Does Swift avoid unsafe-unretained references entirely or does it rear its head when interacting with Obj-C? Swift has strong and weak references that work like ARC. Swift adds unowned references. These references are non-retaining. They differ from weak references and unsafe unretained references: unowned references fail with a runtime error if you try to access the pointed-to object after it has been deallocated. They are intended for cases like views pointing back to superviews, where you need to avoid a retain cycle and you know the pointed-to object will still be alive whenever you use it. They are cheaper than weak references and safer than unsafe-unretained. Swift supports unsafe references using things like the UnsafePointer class. Unsafe interactions with C and Objective-C use such classes, so you shouldn't get unsafe references by surprise. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 6 Feb 2015, at 17:34, Jens Alfke j...@mooseyard.com wrote: On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: // remove observers // unregister for notifications I have to confess I'm still not completely certain whether these are needed under ARC. I remember reading something about at least one of these being handled automatically, but I just skimmed through some docs now and couldn't find anything. I tend to put these in my classes but always wonder whether I strictly need to. I was just checking whether I needed to manually unbind any bindings that I make manually. Looks like I don’t, according to the fragment below from the NSKeyValueBinding.header. Binding obviously involves observation and the header note makes it explicit that removing observers is recommended. I think the one exception is self observation. I think under GC observers may have been removed automatically - cannot quite recall. Header note: Bindings are considered to be a property of the object which is bound (the object the following two methods are sent to) and all information related to bindings should be retained by the object; all standard bindings on AppKit objects (views, cells, table columns, controllers) unbind their bindings automatically when they are released, but if you create key-value bindings for other kind of objects, you need to make sure that you remove those bindings when you release them (observed objects don't retain their observers, so controllers/model objects might continue referencing and messaging the objects that was bound to them). Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 12:46 PM, Jens Alfke j...@mooseyard.com wrote: On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is unsafe_unretained I believe self can be deallocated leaving tableView.delegate as a dangling pointer. This is still a weak reference, it's just unsafe (non-zeroing.) You're right that these need to be cleaned up manually. We prefer to reserve the term weak for safe zeroing weak. Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? Some classes are incompatible with (safe zeroing) weak references. For example, any class that implements custom retain count storage needs additional code to work with weak references. That means AppKit needs to be careful about binary compatibility when it changes an unretained delegate to a weak delegate. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 3:27 PM, Jens Alfke j...@mooseyard.com wrote: On Feb 6, 2015, at 2:00 PM, Greg Parker gpar...@apple.com mailto:gpar...@apple.com wrote: Swift adds unowned references. These references are non-retaining. They differ from weak references and unsafe unretained references: unowned references fail with a runtime error if you try to access the pointed-to object after it has been deallocated. … They are cheaper than weak references and safer than unsafe-unretained. What makes them cheaper than weak references? It sounds like they both have to do the same bookkeeping to track whether the pointed-to object is alive; the only difference is the behavior when accessing the reference after the pointed-to object is dealloced (i.e. treating the pointer as nil vs. failing with an error.) Both of those seem equivalent in complexity. The weak reference system needs to keep track of every variable pointing to a particular object, and erase those variables when the object is deallocated. That is expensive. The unowned reference system does not keep track of every unowned variable. Instead it keeps a count of unowned pointers to a particular object (basically a second reference count of unowned references). If an object's strong reference count reaches zero and its unowned reference count is not zero then the object's destructors are called but the storage itself is not freed. A zombie object is put in its place. If the unowned reference count later decreases to zero then the zombie is freed and everybody is happy. If an unowned reference is used and there is a zombie present, the runtime complains. Unowned references are inefficient if a large object dies but an unowned reference to it lives on, because the object's memory won't be reclaimed until later. They are efficient when the pointed-to object lives as long or longer than the unowned reference variable. -- Greg Parker gpar...@apple.com mailto:gpar...@apple.com Runtime Wrangler ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 1:18 PM, Jonathan Mitchell jonat...@mugginsoft.com wrote: On 6 Feb 2015, at 20:46, Jens Alfke j...@mooseyard.com wrote: Come to think of it, I'm surprised that AppKit delegates are still unsafe-unretained. Why haven't these been converted to safe weak references yet? I presume that AppKIt (all of it?) is not compiled using ARC and hence doesn’t get weak reference tracking et al? The weak reference machinery is available to non-ARC code by calling the runtime functions directly. The system is fragile if you write it by hand, though, so we don't generally recommend it. Why isn AppKit compiled using ARC? Probably because it has a track record as it is and would likely gain nothing in a functional sense. The primary reason is that there is no way to compile a single library that uses ARC and also supports GC. AppKit needs to support GC so it can't use ARC. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On 6 Feb 2015, at 17:34, Jens Alfke j...@mooseyard.com wrote: On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: // remove observers // unregister for notifications I have to confess I'm still not completely certain whether these are needed under ARC. I remember reading something about at least one of these being handled automatically, but I just skimmed through some docs now and couldn't find anything. I tend to put these in my classes but always wonder whether I strictly need to. I would say it is necessary. Warnings result otherwise and unremoved observers do seem to lead to instability. // set any non-weak delegates to nil (NSTableView et al) I think you meant set any _weak_ delegates to nil, i.e. clear the delegate property of any object of whom I'm the delegate. Non-weak doesn't make sense, because if a delegate has a strong reference to self, then self can't possibly be in its dealloc method. Sorry. I wasn’t clear enough probably. Most of my issues centre around NSViewController. Say I have an outlet to an NSTableView and the tableView.delegate = self. The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is unsafe_unretained I believe self can be deallocated leaving tableView.delegate as a dangling pointer. Note that this is only necessary if (a) the other object can outlive self, and (b) the other object could still send the delegate messages in the future. The problem is that there is, I believe, no way to accurately determine whether a or b is true in any particular instance! Recently I have resolved issues where both NSTableView and WebView were sending delegate messages and responder chain actions in situations that I hadn’t expected. A stone dead app is the result. Jonathan ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
ARC dealloc best pratice
I have a mid sized (200+ nib files and associated NSView + NSWindow
controllers) ARC enabled app.
I have Zombie objects ON and have chased down a number of issues, most of which
can be traced back to an incorrectly defined dealloc.
My recent experiences have demonstrated the treacherous nature of these sorts
of issues.
One development machine seemed impervious to an issue, another exhibited it
with unfailing regularity.
So I want to have a best practice template to follow in my dealloc.
At present the template looks like so. When I need a dealloc I paste this in
and fill in the blanks
- (void) dealloc
{
// remove observers
// remove any explicit bindings
// unregister for notifications
// set any non-weak delegates to nil (NSTableView et al)
// invalidate any timers
}
In particular I have issues with non weak delegates and making sure that I get
them set to nil.
I am not aware of anyway of automatically analyzing the source to help ensure
that I haven’t missed something.
Are the following correct:
1. I presume that all the Cocoa framework objects such as NSTableView,
NSPopOver etc that have non weak delegates need set to nil (in other words -
AppKit doesn’t use ARC).
2. This applies even if I don’t have an outlet to say a NSTableView - which
effectively means that I have to have outlets to all such objects.
3. At present I have not tried to ensure that NSWindow delegates (typically
NSWindowController instances) are nil. Should I?
Jonathan
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Fri, Feb 6, 2015, at 08:48 AM, Jonathan Mitchell wrote:
So I want to have a best practice template to follow in my dealloc.
At present the template looks like so. When I need a dealloc I paste this
in and fill in the blanks
- (void) dealloc
{
// remove observers
// remove any explicit bindings
// unregister for notifications
// set any non-weak delegates to nil (NSTableView et al)
// invalidate any timers
}
Dealloc is too late for a lot of this stuff. I try to keep -dealloc as
pure as possible; that is, -dealloc should only be concerned with memory
management.
Removing observers, unbinding, unregistering notifications, and timer
invalidation all happens in -viewWillMoveToWindow: or another similar
place.
--Kyle Sluder
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC dealloc best pratice
On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell jonat...@mugginsoft.com wrote: // remove observers // unregister for notifications I have to confess I'm still not completely certain whether these are needed under ARC. I remember reading something about at least one of these being handled automatically, but I just skimmed through some docs now and couldn't find anything. I tend to put these in my classes but always wonder whether I strictly need to. // set any non-weak delegates to nil (NSTableView et al) I think you meant set any _weak_ delegates to nil, i.e. clear the delegate property of any object of whom I'm the delegate. Non-weak doesn't make sense, because if a delegate has a strong reference to self, then self can't possibly be in its dealloc method. Note that this is only necessary if (a) the other object can outlive self, and (b) the other object could still send the delegate messages in the future. // invalidate any timers This is incorrect, because NSTimer's target property is a strong delegate. So if self is currently the target of any NSTimer, it couldn't be deallocated. In fact, if you're in a dealloc method and still have a reference to such a timer, it indicates there's a refcounting error in your code! Worse, invalidating it in -dealloc will certainly cause a crash because it'll call -release on you during your dealloc… —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
