Re: ARC and C++ structures

On 15 Sep 2021, at 17:39, Matt Jacobson mailto:mhjacob...@me.com>> wrote: On Sep 15, 2021, at 11:21 AM, Tor Arne Vestbø mailto:tor.arne.ves...@qt.io>> wrote: On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote: By default, when an NSWindow is `-

Re: ARC and C++ structures

> On Sep 15, 2021, at 11:21 AM, Tor Arne Vestbø wrote: > > >> On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev >> mailto:cocoa-dev@lists.apple.com>> wrote: >> >> By default, when an NSWindow is `-close`d (which can only happen once in its >> lifetime), > > Interesting. If the NSWindo

Re: ARC and C++ structures

On 14 Sep 2021, at 16:33, Matt Jacobson via Cocoa-dev mailto:cocoa-dev@lists.apple.com>> wrote: By default, when an NSWindow is `-close`d (which can only happen once in its lifetime), Interesting. If the NSWindow is retained elsewhere, can it not be ordered in again? Appreciate any details y

Re: ARC and C++ structures

Thanks. That did it. Interestingly, not only did the Applie Migration tool not flag a potential problem, but the docs on NSWindow and releaseWhenClosed don't even hint of it. > Hi Tom, > > > On Sep 14, 2021, at 9:53 AM, Tom Doan via Cocoa-dev > > wrote: > > > > I have a multiple platform app

Re: ARC and C++ structures

Hi Tom, > On Sep 14, 2021, at 9:53 AM, Tom Doan via Cocoa-dev > wrote: > > I have a multiple platform application (Windows, Mac, GTK) that is > primarily organized using C++ with Objective-C used for the > Mac-specific interface. I recently switched to use ARC (as we are > using Scintilla wh

Re: ARC

Also turn on Zombie Objects and the other diagnostic features in Xcode edit Scheme -> Diagnostics. -Owen > On Aug 26, 2019, at 1:43 PM, Jean-Daniel via Cocoa-dev > wrote: > > A better way to investigate such issue is using the memory debugging tools in > Instrument IMHO. > That would let you

Re: ARC problems

>> Is that view controller voiding its own self reference? No. >> Is it possible to switch out the view controller that i disappearing with another one and see if that also disappears? We've already wasted 2 weeks trying to debug this. It's time to move on. We won't finish in time for Catalina,

Re: ARC problems

On 4 Sep 2019, at 0:18, Turtle Creek Software via Cocoa-dev wrote: The startup code was created 3 years ago when we were new to Cocoa, probably from one of the HIllegass books. Do you manually load nibs (as opposed to rely on the framework to load MainMenu.nib)? In a previous post you wrote

Re: ARC problems

> Le 4 sept. 2019 à 00:18, Turtle Creek Software a > écrit : > > The app delegate is NOT being deallocated prematurely- we have a breakpoint > there to check. > > We don't allocate the app delegate explicitly, so I had to set a breakpoint > in init() to see when it happens. > It's created i

Re: ARC problems

Is it possible to switch out the view controller that i disappearing with another one and see if that also disappears? Is that view controller voiding its own self reference? > On Sep 3, 2019, at 5:18 PM, Turtle Creek Software via Cocoa-dev > wrote: > > The app delegate is NOT being deallocat

Re: ARC problems

The app delegate is NOT being deallocated prematurely- we have a breakpoint there to check. We don't allocate the app delegate explicitly, so I had to set a breakpoint in init() to see when it happens. It's created in main() via NSApplicationMain. Presumably its end of scope would be when main en

Re: ARC problems

> Le 3 sept. 2019 à 02:33, Turtle Creek Software via Cocoa-dev > a écrit : > > Thanks for all the suggestions for the problems we had with a controller > being > deallocated unexpectedly under ARC. Unfortunately, none of them fixed it. > > We do need to get back to regular app programming, so

Re: ARC

I highly doubt that setting a breakpoint on objc_retain would be useful: it’s called too often. Just launching Calculator, for example, hits the function over 20 times, so even a conditional breakpoint would make execution prohibitively slow. I would expect you to have more luck finding ever

Re: ARC

On 8/26/2019 8:28 PM, Turtle Creek Software via Cocoa-dev wrote: @property (weak) GSOutlineWindowController *mainWindowController; self.mainWindowController = [[GSOutlineWindowController alloc] initWithWindowNibName : @"GSOutlineWindowController"]; [self.mainWindowController showWindow : s

Re: ARC

>> @property (weak) GSOutlineWindowController *mainWindowController; >>self.mainWindowController = [[GSOutlineWindowController alloc] initWithWindowNibName : @"GSOutlineWindowController"]; [self.mainWindowController showWindow : self]; Sadly, nothing changes after the syntax changes. @proper

Re: ARC

A better way to investigate such issue is using the memory debugging tools in Instrument IMHO. That would let you see all stack traces of retain/release calls. > Le 26 août 2019 à 04:14, Turtle Creek Software via Cocoa-dev > a écrit : > > In GSAppDelegate.h > GSOutlineWindowController *mainWi

Re: ARC

In GSAppDelegate.h GSOutlineWindowController *mainWindowController; In GSAppDelegate.mm - (void) showOutlineWindow { if (mainWindowController == NULL) mainWindowController = [[GSOutlineWindowController alloc] initWithWindowNibName : @"GSOutlineWindowController"]; [mainWindowC

Re: ARC

On 8/24/2019 1:44 PM, Turtle Creek Software via Cocoa-dev wrote: Our app delegate class is not deallocated. The window controller is deallocated despite the member reference there. If we keep the second strong reference to the controller, then the outline view is deallocated instead. Nothing r

Re: ARC

> On Aug 24, 2019, at 4:46 AM, Turtle Creek Software > wrote: > > Our app delegate class is not deallocated. The window controller is > deallocated > despite the member reference there. That should not be possible. Could you paste the exact line of code that declares the window-controller r

Re: ARC

Sometimes the best approach when something seems magical or extremely unexpected is to step away to the marker board and draw pictures and a “movie” storyboard of what’s going on, tallying up visually everything. Unilaterally using strong or weak references is not the answer. Often when I go thr

Re: ARC

Our app delegate class is not deallocated. The window controller is deallocated despite the member reference there. If we keep the second strong reference to the controller, then the outline view is deallocated instead. Nothing references the view except being in the .xib file for the window con

Re: ARC

> > BTW, one site we looked at describes ARC as "kind of like a Japanese B-horror > movie". That seems accurate. > I don’t know what site wrote that but it couldn’t be less accurate. ARC is one of the better pieces of technology Apple introduced into Objective-C and it cut down on a huge num

Re: ARC

> On Aug 23, 2019, at 2:17 PM, Casey McDermott via Cocoa-dev > wrote: > > After we finished, the controller for our main window started being > deallocated some random time after launch. > Apparently the erroneous strong references were keeping it alive. AppKit delegates, like NSWindow.deleg

Re: ARC

Sorry, it's a Mac app, written in Objective-C and C++. We checked the Memory Graph and nothing seemed amiss. On Fri, Aug 23, 2019 at 6:51 PM Alex Zavatone wrote: > Casey, it it’s an iOS app, read up on strong and weak and use the > storyboard to breat your first screen. > > Assuming it’s an iOS

Re: ARC

Casey, it it’s an iOS app, read up on strong and weak and use the storyboard to breat your first screen. Assuming it’s an iOS app… Why are you allocating the controller in the app delegate? Are you embedding it in a Nav controller? ARC is fantastic. The view controller is within the wi

Re: ARC

> On 23 Aug 2019, at 2:17 pm, Casey McDermott via Cocoa-dev > wrote: > > We allocate the controller in our app delegate class. It's a member but > apparently that is not a > strong enough reference, so the controller is released at the end of the > scope. What is best practice to hold a stron

Re: ARC

Casey, is this a Mac app or an iOS app? > On Aug 23, 2019, at 4:17 PM, Casey McDermott via Cocoa-dev > wrote: > > We allocate the controller in our app delegate class ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin

Re: ARC [was Protecting against "app nap"]

If that wasn’t called out clearly in that non-ARC class’s documentation/header, then that non-ARC class was Doing It Wrong(tm). > On May 13, 2016, at 2:55 AM, Dave wrote: > > Hi, > > The other thing to watch out for is if you have non ARC Classes in your > project, you can forget that they a

Re: ARC [was Protecting against "app nap"]

Hi, The other thing to watch out for is if you have non ARC Classes in your project, you can forget that they are using assign rather than weak for properties (so the reference doesn’t get zeroed) that can lead to sending message to objects that have been destroyed if you are not careful. You h

Re: ARC [was Protecting against "app nap"]

> On May 12, 2016, at 1:16 AM, Jonathan Taylor > wrote: > > you would definitely recommend ARC then, would you? Totally. As Roland said, I would never go back. > I've been a bit put off by what seems like regular questions on the list(s) > about debugging and fixing edge cases where ARC does

Re: ARC [was Protecting against "app nap"]

I can’t imagine going back to manual retain release. ARC lifted hours of work away from writing code because you just use objects and they stay when they need to stay go away when you’re done with them. I see hardly any questions about ARC at all, there were some at the very start, but they pete

Re: ARC [was Protecting against "app nap"]

Hi Jens, Thanks again for your reply. I'm sure this has been done to death over the years on the list, but... you would definitely recommend ARC then, would you? I've been a bit put off by what seems like regular questions on the list(s) about debugging and fixing edge cases where ARC doesn't w

Re: ARC code in a non ARC app. iOS

On 24 Feb 2016, at 00:25, Alex Zavatone wrote: > Would it be recommended to package my ARC code with ARC turned off and > package that in a framework and then link to that from the non ARC app that > will need to load it? Nope, that would leak all over the place, or dangle pointers depending o

Re: ARC code in a non ARC app. iOS

On Feb 25, 2016, at 22:15 , Uli Kusterer wrote: > > Did you really mean +newBlah ? Not something like +blahWithX: or just +blah? > Because +new is documented to just be a shorthand for +alloc followed by > -init on the result, so +newBlah behaving differently than +new sounds kinda > inconsist

Re: ARC code in a non ARC app. iOS

On 24 Feb 2016, at 00:47, Quincey Morris wrote: > For example, an object obtained via [[…alloc]init…] is generally assumed to > be returned with a +1 ownership, but an object obtained via a class method > named ‘newXXX…’ is generally assumed to be returned with +0 ownership. Did you really me

Re: ARC code in a non ARC app. iOS

> On 25 Feb 2016, at 17:43, Jens Alfke wrote: > > >> On Feb 25, 2016, at 8:35 AM, Dave > > wrote: >> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to have the subclass Non-ARC too. >>> >>> This is not true. For example, NSView

Re: ARC code in a non ARC app. iOS

> On Feb 25, 2016, at 8:35 AM, Dave wrote: > >>> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to >>> have the subclass Non-ARC too. >> >> This is not true. For example, NSView is not ARC but you can write ARC >> subclasses of it. > > I didn’t say it was impossible, b

Re: ARC code in a non ARC app. iOS

> On 24 Feb 2016, at 23:57, Greg Parker wrote: > > >> On Feb 24, 2016, at 2:31 AM, Dave wrote: >> >> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to >> have the subclass Non-ARC too. > > This is not true. For example, NSView is not ARC but you can write ARC > subcla

Re: ARC code in a non ARC app. iOS

Tangentially related: I have a bug ( rdar://10894595 ) open on the Developer Tools (Xcode/clang) to add a #pragma to turn on/off ARC in the source code, for dealing with just such situations. I dunno’ how much work it would be to implement… I imagine not all that much for somebody familiar wi

Re: ARC code in a non ARC app. iOS

> On Feb 24, 2016, at 2:31 AM, Dave wrote: > > Also, beware subclassing a Non-ARC Class in an ARC Project - you have to have > the subclass Non-ARC too. This is not true. For example, NSView is not ARC but you can write ARC subclasses of it. -- Greg Parker gpar...@apple.com Runtime

Re: ARC code in a non ARC app. iOS

Also, beware subclassing a Non-ARC Class in an ARC Project - you have to have the subclass Non-ARC too. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderator

Re: ARC code in a non ARC app. iOS

Ok time for me to establish base test cases in very simple cases first. Sent from my iPhone > On Feb 23, 2016, at 6:47 PM, Quincey Morris > wrote: > >> On Feb 23, 2016, at 15:25 , Alex Zavatone wrote: >> >> Would it be recommended to package my ARC code with ARC turned off and >> package th

Re: ARC code in a non ARC app. iOS

> On Feb 23, 2016, at 3:46 PM, Alex Zavatone wrote: > > Aha! > > Awesome. That will work nicely. > > Now my concern is the compiled c lib that my code links to. Do I also have > to rebuild that with non ARC flags too? The ARC flags only affect the Objective-C and Objective-C++ compilers. P

Re: ARC code in a non ARC app. iOS

On Feb 23, 2016, at 15:25 , Alex Zavatone wrote: > > Would it be recommended to package my ARC code with ARC turned off and > package that in a framework and then link to that from the non ARC app that > will need to load it? This would be a really bad idea. :) Your code has no retains and rel

Re: ARC code in a non ARC app. iOS

Aha! Awesome. That will work nicely. Now my concern is the compiled c lib that my code links to. Do I also have to rebuild that with non ARC flags too? Sent from my iPhone > On Feb 23, 2016, at 6:33 PM, Greg Parker wrote: > > >> On Feb 23, 2016, at 3:25 PM, Alex Zavatone wrote: >> >> Wo

Re: ARC code in a non ARC app. iOS

> On Feb 23, 2016, at 3:25 PM, Alex Zavatone wrote: > > Would it be recommended to package my ARC code with ARC turned off and > package that in a framework and then link to that from the non ARC app that > will need to load it? Building a separate dylib or static archive is not necessary, bu

Re: ARC code in a non ARC app. iOS

Ok. Great. I knew there would be some scariness in there I'd need to know about. Are there any tools in Instruments or approaches to make sure I'm not going to destroy the universe when calling my stuff? I'm planning on starting by loading a placeholder one screen storyboard as an initial test

Re: ARC code in a non ARC app. iOS

Yeah, it does. I was thinking about it bassackwardsly. Would it be recommended to package my ARC code with ARC turned off and package that in a framework and then link to that from the non ARC app that will need to load it? Thank you, sir. AZ Sent from my iPhone > On Feb 23, 2016, at 6:16

Re: ARC code in a non ARC app. iOS

On Feb 23, 2016, at 13:30 , Alex Zavatone wrote: > > Now, I'm familiar with the -fno-objc-arc build flags to disable compiling one > file at a time, but is there any possibility to include iOS code that does > use ARC within an app that doesn't? You can mix-and-match ARC source with non-ARC (M

Re: ARC code in a non ARC app. iOS

> On Feb 23, 2016, at 1:30 PM, Alex Zavatone wrote: > > Hi all. I'm in the middle of looking at an interesting problem on the iOS > side. > > We have our code that is ARC and uses external compiled C libs that I'm being > asked to plug into another iOS project that's significantly larger tha

Re: ARC and IBOutlet - strong vs weak......

Your reference is weak, old man… oh, wait, that’s kung-fu…. um…. Seriously - I always make my references strong unless I have a good reason not to (avoiding retain cycles is one such good reason). Weak references, while nice for what they do, do have some overhead and other drawbacks (like the

Re: ARC and IBOutlet - strong vs weak......

> On 5 Dec 2015, at 17:31, Alex Zavatone wrote: > > Weak. > > There is only one reference to it, right? > It seems that the actual answer is “it depends”……. But making them strong unless you specifically need to do otherwise seems like the best practise approach….. Dave ___

Re: ARC and IBOutlet - strong vs weak......

"weak" is also inherently incompatible with KVO, because no notification is sent when the weak reference goes away. And that'll wreak havoc, especially when you are using Cocoa Bindings. Gerd > On Dec 6, 2015, at 05:52, Dave wrote: > >> >> On 4 Dec 2015, at 18:04, Quincey Morris >> wrote:

Re: ARC and IBOutlet - strong vs weak......

> On 4 Dec 2015, at 18:04, Quincey Morris > wrote: > > On Dec 4, 2015, at 06:16 , Dave > wrote: >> >> I asked about this on Twitter to an engineer on the IB team and he confirmed >> that strong should be the default and that the developer docs are being >> up

Re: ARC and IBOutlet - strong vs weak......

> On Dec 4, 2015, at 12:05, Mike Throckmorton > wrote: > > Quincey Morris Friday, December 4, 2015 10:04 AM > >> That sounds like a definitive answer. So you’re asking us because … why? > > Definitive for the leading question, but not the secondary: > >> If strong, do I need to set the outle

Re: ARC and IBOutlet - strong vs weak......

Quincey Morris Friday, December 4, 2015 10:04 AM That sounds like a definitive answer. So you’re asking us because … why? Definitive for the leading question, but not the secondary: If strong, do I need to set the outlets to nil in the corresponding dealloc method? I had tested this and i

Re: ARC and IBOutlet - strong vs weak......

On Dec 4, 2015, at 06:16 , Dave wrote: > > I asked about this on Twitter to an engineer on the IB team and he confirmed > that strong should be the default and that the developer docs are being > updated. That sounds like a definitive answer. So you’re asking us because … why? Here’s how I un

Re: ARC, blocks, capture variables

On Sep 28, 2015, at 17:33 , Scott Ribe wrote: > > Ah, I just tried assignment to weak ivar then registration, gets the same > value. Anyway, avoiding monkeying with temp vars to fool the compiler is why > I re-did the API. I’d say that the monkeying comes from ensuring you get the same pointer

Re: ARC, blocks, capture variables

On Sep 28, 2015, at 6:24 PM, Quincey Morris wrote: > > On Sep 28, 2015, at 17:14 , Scott Ribe wrote: >> >> "Assigning block literal to a weak variable; object will be released after >> assignment" > > Well, you wouldn’t assign a literal there. You want the exact same block > pointer for bot

Re: ARC, blocks, capture variables

> On Sep 28, 2015, at 5:53 PM, Quincey Morris > wrote: > > You lost me at “I”, because it’s not clear whether you are the library or the > client at that point. Was ‘authfun’ a property of the window controller (the > client/owner?) or something in the library? > > Is the ‘id’ in the new API

Re: ARC, blocks, capture variables

On Sep 28, 2015, at 15:20 , Scott Ribe wrote: > > The essential problem was in the library design, not the calls. I was keeping > self.authfun as an instance var for the sole purpose of unregistering the > callback when the owner (a window controller) was being torn down. The better > way (IMO

Re: ARC, blocks, capture variables

On Sep 27, 2015, at 7:51 PM, Scott Ribe wrote: > > On Sep 27, 2015, at 7:03 PM, Quincey Morris > wrote: >> >> IIRC you can simply assign ‘self’ to a local variable just before assigning >> to ‘fun', and use the local variable name instead of ‘self’ inside the block. > > Well, that does work

Re: ARC, blocks, capture variables

On Sep 27, 2015, at 7:03 PM, Quincey Morris wrote: > > IIRC you can simply assign ‘self’ to a local variable just before assigning > to ‘fun', and use the local variable name instead of ‘self’ inside the block. Well, that does work. Thanks! -- Scott Ribe scott_r...@elevated-dev.com http://w

Re: ARC, blocks, capture variables

On Sep 27, 2015, at 17:17 , Scott Ribe wrote: > > But I know that it does not result in a retain cycle, because I nil out fun > at the appropriate time. So how to get rid of the warning? IIRC you can simply assign ‘self’ to a local variable just before assigning to ‘fun', and use the local va

Re: ARC and Manual Memory Management

I found fmdb’s solution instructive and very helpful. If you download the source and take a look it might give you some ideas. Rob ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin reques

Re: ARC and Manual Memory Management

On Mon, Aug 10, 2015 at 3:51 PM, Uli Kusterer wrote: > > > On 10 Aug 2015, at 21:12, Dave wrote: > > > > > >> On 10 Aug 2015, at 19:11, Uli Kusterer > wrote: > >> > >> On 10 Aug 2015, at 13:59, Dave wrote: > >>> Has anyone come up with a way of having the source code support both > ARC and Man

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 21:12, Dave wrote: > > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >> On 10 Aug 2015, at 13:59, Dave wrote: >>> Has anyone come up with a way of having the source code support both ARC >>> and Manual Memory Management without using #IFDEF or #IF ? >>> >>> I’ve

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 12:12 PM, Dave wrote: > > If it just ignored those constructs, it was be much less confusing, simply > because there would only one set of source code. It would be a mess, honestly. If you build + test a source file with ARC it’d be very easy to break it for MRR by forge

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 12:12 PM, Dave wrote: > >> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: >> >>> On 10 Aug 2015, at 13:59, Dave wrote: >>> >>> Has anyone come up with a way of having the source code support both ARC >>> and Manual Memory Management without using #IFDEF or #IF ? >>> >>

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 19:11, Uli Kusterer wrote: > > On 10 Aug 2015, at 13:59, Dave wrote: >> Has anyone come up with a way of having the source code support both ARC and >> Manual Memory Management without using #IFDEF or #IF ? >> >> I’ve never understood why the compiler doesn’t just ignore

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 1:11 PM, Uli Kusterer > wrote: > > The only reason I'm aware of is if you need to port to a platform that > doesn't support libArclite (like really old Mac/iOS versions). Targeting arclite isn’t such a good idea these days, IMO; I’ve found the later versions of Xcode som

Re: ARC and Manual Memory Management

On 10 Aug 2015, at 13:59, Dave wrote: > Has anyone come up with a way of having the source code support both ARC and > Manual Memory Management without using #IFDEF or #IF ? > > I’ve never understood why the compiler doesn’t just ignore code like: > > [super dealloc]; > > [MyObj release]; > >

Re: ARC and Manual Memory Management

> On Aug 10, 2015, at 8:35 AM, Dave wrote: > > That’s fair enough, I was wondering if there was any deep reason. The thing > is I have library classes that I use in older projects that are non-ARC, I > was trying avoid having two sets of more or less identical files. Just add the compiler fl

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 13:21, Roland King wrote: > > >> On 10 Aug 2015, at 19:59, Dave > > wrote: >> >> Hi, >> >> Has anyone come up with a way of having the source code support both ARC and >> Manual Memory Management without using #IFDEF or #IF ? >> >> I’ve n

Re: ARC and Manual Memory Management

> On 10 Aug 2015, at 19:59, Dave wrote: > > Hi, > > Has anyone come up with a way of having the source code support both ARC and > Manual Memory Management without using #IFDEF or #IF ? > > I’ve never understood why the compiler doesn’t just ignore code like: > > [super dealloc]; > > [MyObj

Re: ARC and Manual Memory Management

On Monday, August 10, 2015, Dave wrote: > Hi, > > Has anyone come up with a way of having the source code support both ARC > and Manual Memory Management without using #IFDEF or #IF ? You could use a macro, and if ARC is enabled, then simply have it evaluated to do nothing. This is common in ot

Re: ARC dealloc best pratice

On Feb 6, 2015, at 11:34:35, Kyle Sluder 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 > invalida

Re: ARC dealloc best pratice

> On 10 Feb 2015, at 21:20, Sean McBride 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

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 situat

Re: ARC dealloc best pratice

> On 6 Feb 2015, at 17:34, Kyle Sluder 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 sh

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 3:27 PM, Jens Alfke wrote: > >> On Feb 6, 2015, at 2:00 PM, Greg Parker > > wrote: >> >> Swift adds "unowned" references. These references are non-retaining. They >> differ from weak references and unsafe unretained references: unowned >> referen

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 2:00 PM, Greg Parker 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 h

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 1:48 PM, Jonathan Mitchell wrote: > >> On 6 Feb 2015, at 21:31, Greg Parker 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 i

Re: ARC dealloc best pratice

> On 6 Feb 2015, at 21:31, Greg Parker 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, a

Re: ARC dealloc best pratice

> On 6 Feb 2015, at 17:34, Jens Alfke wrote: > > >> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell >> 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

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 1:18 PM, Jonathan Mitchell wrote: > >> On 6 Feb 2015, at 20:46, Jens Alfke 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 (a

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 12:46 PM, Jens Alfke wrote: > >> On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell >> 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

Re: ARC dealloc best pratice

> On 6 Feb 2015, at 20:46, Jens Alfke 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 refe

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 12:46 PM, Jens Alfke wrote: > > >> On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell >> 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 dangl

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell > 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

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.

Re: ARC dealloc best pratice

> On 6 Feb 2015, at 17:34, Kyle Sluder 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 ubiqui

Re: ARC dealloc best pratice

> On 6 Feb 2015, at 17:34, Jens Alfke wrote: >> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell >> 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 somet

Re: ARC dealloc best pratice

> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell 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 automatica

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 > >

Re: ARC query

> On Jan 7, 2015, at 1:11 PM, Mike Abdullah wrote: > > >> On 7 Jan 2015, at 20:55, Sean McBride wrote: >> >> On Wed, 7 Jan 2015 12:02:16 -0600, Ken Thomases said: >> >>> Short answer: yes, the alert is retained. >> >> Meaning that one must use the weak/strong dance pattern like this? >> >>

Re: ARC query

> On Jan 7, 2015, at 12:55, Sean McBride wrote: > > On Wed, 7 Jan 2015 12:02:16 -0600, Ken Thomases said: > >> Short answer: yes, the alert is retained. > > Meaning that one must use the weak/strong dance pattern like this? No. The weak/strong dance would only be needed if NSAlert held on to

Re: ARC query

> On 7 Jan 2015, at 20:55, Sean McBride wrote: > > On Wed, 7 Jan 2015 12:02:16 -0600, Ken Thomases said: > >> Short answer: yes, the alert is retained. > > Meaning that one must use the weak/strong dance pattern like this? > > NSAlert *alert = [NSAlert new]; > alert.alertStyle = NSWarningAler

Re: ARC query

On Wed, 7 Jan 2015 12:02:16 -0600, Ken Thomases said: >Short answer: yes, the alert is retained. Meaning that one must use the weak/strong dance pattern like this? NSAlert *alert = [NSAlert new]; alert.alertStyle = NSWarningAlertStyle; alert.messageText = @“Do not touch!"; __weak NSAlert* weakA

Re: ARC query

On Jan 7, 2015, at 9:32 AM, Jonathan Mitchell wrote: > I use this construct quite a lot without really thinking about it under ARC > I don’t retain a reference to the alert. > > Does -beginSheetModalForWindow: completionHandler: cause the receiver to be > retained until after the completion han

  1   2   3   4   >