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

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

Re: ARC and C++ structures

gt; 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 which recently switched to ARC). However, I am > > get

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

ARC and C++ structures

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 which recently switched to ARC). However, I am getting a zombied release

Re: Thoughts on ARC

On Wed, 2 Oct 2019 10:50:19 +1300, Sam Ryan via Cocoa-dev said: >That was a good read, thank you for passing that on. It highlights a good >point, that Apple is itself releasing applications with non-Mac UI (News, >Home, Stocks, Voice Memos are mentioned in that article). Another way to look at

Re: Thoughts on ARC

—Jens > On Oct 1, 2019, at 2:50 PM, Sam Ryan wrote: > > In fact those applications are forced upon the user in a way that I've never > seen before, as if they are core system components. You mean pre-installed? There have always been plenty of bundled apps like Mail, Calendar, Chess, etc.

Re: Thoughts on ARC

That was a good read, thank you for passing that on. It highlights a good point, that Apple is itself releasing applications with non-Mac UI (News, Home, Stocks, Voice Memos are mentioned in that article). In fact those applications are forced upon the user in a way that I've never seen before, as

Re: Thoughts on ARC

> On Sep 30, 2019, at 5:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross platform > (non mobile at least). I would not have recommended a non-native approach > until

Re: Thoughts on ARC

> On Sep 30, 2019, at 4:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to bridge to c++, and is cross platform > (non mobile at least). I would not have recommended a non-native approach > until

Re: Thoughts on ARC

No apology necessary, I'm pained by the same problems as you mentioned! On Tue, 1 Oct 2019 at 14:00, Jens Alfke wrote: > > > On Sep 30, 2019, at 4:57 PM, Sam Ryan wrote: > > I tried a completely new approach - Electron. I have found Electron to be > surprisingly quick to prototype, easy to

Re: Thoughts on ARC

I have recently looked at utilising Swift to update an old Carbon based application. I stopped pursuing this path Swiftly, in part because of lack of good support for sockets and generally problematic use of CG* code. I tried a completely new approach - Electron. I have found Electron to be

Re: Thoughts on ARC

> Le 30 sept. 2019 à 17:16, Robert Walsh via Cocoa-dev > a écrit : > > > Swift may be the solution, but it's built on a weak foundation. It makes > cross-platform development almost impossible. The TIOBE index shows Swift > declining (and Objective-C increasing). So, maybe it isn't. > > I

Re: Thoughts on ARC

> On Sep 30, 2019, at 8:16 AM, Robert Walsh via Cocoa-dev > wrote: > > however, to use it to do anything other than building a desktop or IOS GUI > application seems to result in code with messy syntax and what seem to me to > be hacks in order to bridge between NS* and CG* code. (Lots of

Re: Thoughts on ARC

Swift may be the solution, but it's built on a weak foundation. It makes cross-platform development almost impossible. The TIOBE index shows Swift declining (and Objective-C increasing). So, maybe it isn't. I don't yet have a lot of experience with Swift, but I would already argue that Swift

Re: ARC

elf]; >> } >> >> We don't do any ref-counting at all. A search for CFRetain and CFRelease >> showed zero items. >> >> I would say that ARC is certainly way better than the previous manual >> ref-counting. That must have been hellish. >> Fortunately we

Re: Thoughts on ARC

> On Sep 27, 2019, at 1:21 PM, Jens Alfke wrote: > > I was typing a lengthy answer, but it occurred to me it's basically the same > reason why Apple didn't release macOS for generic PCs ('hackintoshes') and in > fact actively made it difficult for anyone to port macOS. It's because it >

Re: Thoughts on ARC

> On Sep 27, 2019, at 9:20 AM, Richard Charles via Cocoa-dev > wrote: > > What I wish Apple would do is release a cross platform Objective-C (and > Swift) solution. ... > The Mac vs Windows war is over and long gone so why doesn’t Apple help out > the small developer and release a cross

Re: Thoughts on ARC

t makes sense that Cocoa programmers much prefer ARC to MRC. Doing it > manually is easy to break and hard to debug. However, the fact that ARC is > not exception-safe concerns me. It suggests that Cocoa still manages ref > counts manually, somewhere under the hood. We've had two

Re: Thoughts on ARC

On 27 Sep 2019, at 14:19, Turtle Creek Software via Cocoa-dev wrote: It makes sense that Cocoa programmers much prefer ARC to MRC. Doing it manually is easy to break and hard to debug. However, the fact that ARC is not exception-safe concerns me. Cocoa in general is not exception safe

Thoughts on ARC

them all with a stack-based watcher class. It adds a reference in the constructor, and removes it in the destructor. Simpler, more reliable, and exception-safe. It makes sense that Cocoa programmers much prefer ARC to MRC. Doing it manually is easy to break and hard to debug. However, the fact

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

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

Re: ARC problems

the app has been running OK otherwise. The problems > only started when we read about circular references > and started making up-references __weak. > > BTW the Clang specs for ARC mention that it's not exception-safe. If I > understand correctly, > strong references will lea

Re: ARC problems

have flaws, but the app has been running OK otherwise. The problems > only started when we read about circular references > and started making up-references __weak. > > BTW the Clang specs for ARC mention that it's not exception-safe. If I > understand correctly, > strong refe

Re: ARC problems

read about circular references and started making up-references __weak. BTW the Clang specs for ARC mention that it's not exception-safe. If I understand correctly, strong references will leak, and weak references are released. We don't throw any Cocoa exceptions but maybe the system does. Casey

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

ARC problems

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 it will just stay a mystery. I was hoping we were doing something obviously dumb, but I

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. >> >> We tried that last week. The problem with ARC debugging is that >>

Re: ARC

he problem with ARC debugging is that breakpoints in dealloc() happen long after the release. You know it died, but not when or how. Sometimes we turn off ARC for one class with compiler directives, then breakpoint on release. Have you tried turning on NSZombie etc.? There are a bunch of neat debug helpe

Re: ARC

ter the syntax changes. @property (strong) also fails. >> 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. We tried that last week. The problem with ARC debugging is that breakpoi

Re: ARC

nWindowController showWindow : self]; > } > > We don't do any ref-counting at all. A search for CFRetain and CFRelease > showed zero items. > > I would say that ARC is certainly way better than the previous manual > ref-counting. That must have been hellish. > Fortunatel

Re: ARC

oller"]; [mainWindowController showWindow : self]; } We don't do any ref-counting at all. A search for CFRetain and CFRelease showed zero items. I would say that ARC is certainly way better than the previous manual ref-counting. That must have been hellish. Fortunately we only started the Carbon->Cocoa

Re: ARC

references the view except being in the .xib file for the window controller. That doesn't seem possible. You must be doing something else that breaks things. A strong reference is a strong reference, an object doesn't get deallocated if it's still held. Either you have files where ARC is still

Re: ARC

g code that messes with ref-counting, I.e. by using CFRetain/Release on Obj-C objects? —Jens (And let me chime in that ARC is an excellent feature. Cocoa used to have ‘true’ garbage collection as an option, but it was rarely used on Mac due to memory and performance impact, and never

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

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

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

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

Re: ARC

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 window. I know I’ll need more info to > help. > > > > > On Aug 23, 2019,

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

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

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

ARC

We started out assuming that ARC was like Python or Java, where you could just allocate objects and it would manage their lifetimes automatically. Then we read about the complexities of ARC, and started adding __weak to upstream references. After we finished, the controller for our main window

Re: Draw an arc given 2 angles.

gt; wrote: > > I've been googling without great success so far. > > I would like to draw a 6px thick red arc (not wedge), 0º at the top of the > screen, and from say 60° - 110º. Assume I have to create a UIBezierPath, > and then create a CAShapeLayer with that bezier path? Then add

Re: Draw an arc given 2 angles.

Saagar Jha > On Jan 25, 2018, at 09:47, Eric E. Dolecki <edole...@gmail.com> wrote: > > I've been googling without great success so far. > > I would like to draw a 6px thick red arc (not wedge), 0º at the top of the > screen, and from say 60° - 110º. Assume I have

Draw an arc given 2 angles.

I've been googling without great success so far. I would like to draw a 6px thick red arc (not wedge), 0º at the top of the screen, and from say 60° - 110º. Assume I have to create a UIBezierPath, and then create a CAShapeLayer with that bezier path? Then add the shape layer to a UIView that I

Re: adding arc to a fundamentally non-arc project

; a écrit : > > Trying to move from QTKit to AVKit. Compiling on El Capitan (at the moment). > So I have a handler that is arc and handles all the AVKit stuff and compiled > with the -fobjc-arc flag in the build phases... I create and assign the > handler to a document ob

Re: adding arc to a fundamentally non-arc project

Have you added the proper lib to your target? Whatever lib file holds AVKit. > On Jul 15, 2017, at 4:00 PM, Matthew Weinstein <mwein...@kent.edu> wrote: > > Trying to move from QTKit to AVKit. Compiling on El Capitan (at the moment). > So I have a handler that is arc and han

Re: adding arc to a fundamentally non-arc project

> On Jul 15, 2017, at 2:00 PM, Matthew Weinstein <mwein...@kent.edu> wrote: > > Trying to move from QTKit to AVKit. Compiling on El Capitan (at the moment). > So I have a handler that is arc and handles all the AVKit stuff and compiled > with the -fobjc-arc flag in the bui

adding arc to a fundamentally non-arc project

Trying to move from QTKit to AVKit. Compiling on El Capitan (at the moment). So I have a handler that is arc and handles all the AVKit stuff and compiled with the -fobjc-arc flag in the build phases... I create and assign the handler to a document object using the myhandler = [[MWArcHandler

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 <d...@looktowindward.com> wrote: > > Hi, > > The other thing to watch out for is if you have non ARC Class

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

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

> On May 12, 2016, at 1:16 AM, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> > 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(

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

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

Re: How to keep things alive in Arc?

> On May 9, 2016, at 6:38 AM, gerti-cocoa...@bitart.com wrote: > This was recommended to me by folks "in the know": > > Thing *aThing = [ Thing new ]; > > ... > > (void)aThing; This is not guaranteed to keep aThing alive for its full scope. You should use the

Re: How to keep things alive in Arc?

> void *thingData = [ aThing data ];// pointer to a buffer owned by > aThing > > … never use aThing after this point → Arc might release aThing right now > … but do lots of things with thingData > > … no more need for thingData > [ aThing release]; > &g

Re: How to keep things alive in Arc?

> On 9 May 2016, at 19:17, Dave <d...@looktowindward.com> wrote: > > Hi, > > Well if “thing” is used only within the method you don’t have to do anything > - ARC will keep it alive until the local you have assigned it to goes out of > scope. No that’s not tru

Re: How to keep things alive in Arc?

Hi, Well if “thing” is used only within the method you don’t have to do anything - ARC will keep it alive until the local you have assigned it to goes out of scope. If you want to use use it beyond the scope of the local method/object but not return it from the method, then assign

Re: How to keep things alive in Arc?

On May 8, 2016, at 22:12 , Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: > > Is there any other documentation (e.g. with a list of all __attribute__s and > their respective meaning)? Documented here for ARC: http://clang.llvm.org/docs/AutomaticReferenceCounting.html

Re: How to keep things alive in Arc?

to a buffer owned by >> aThing >> >> … never use aThing after this point → Arc might release aThing right now >> … but do lots of things with thingData >> >> … no more need for thingData >> [ aThing release]; >> >> How to prevent Arc to release

Re: How to keep things alive in Arc?

er to a buffer owned by > aThing > > … never use aThing after this point → Arc might release aThing right now > … but do lots of things with thingData > > … no more need for thingData > [ aThing release]; > > How to prevent Arc to re

Re: How to keep things alive in Arc?

> On 9 May 2016, at 10:11, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: > > Thing *aThing = [ Thing new ]; > > void *thingData = [ aThing data ];// pointer to a buffer owned by > aThing > > … never use aThing after this point → Arc might release aT

How to keep things alive in Arc?

Thing *aThing = [ Thing new ]; void *thingData = [ aThing data ]; // pointer to a buffer owned by aThing … never use aThing after this point → Arc might release aThing right now … but do lots of things with thingData … no more need for thingData [ aThing release]; How to prevent Arc

Re: Converting to ARC and blocks

jC pointer type like that, they retain it. > > That's not always desired, either for efficiency reasons or because it > > introduces retain cycles, and so __block is sometimes used in non-ARC code > > as a (very inefficient) way to prevent that retain. That doesn't work in > > ARC

Re: Converting to ARC and blocks

e code, where it really *was* allocated and assigned inside the block.   When blocks capture a value of ObjC pointer type like that, they retain it. That's not always desired, either for efficiency reasons or because it introduces retain cycles, and so __block is sometimes used in non-ARC code as a

Re: Converting to ARC and blocks

> On May 2, 2016, at 10:38 AM, Steve Mills <sjmi...@mac.com> wrote: > I'm working on a project that's had to support older hardware/software until > now, so we can *finally* convert to ARC. Since it's been almost a year since > I've worked on anything that used ARC, I'm a li

Re: Converting to ARC and blocks

On May 02, 2016, at 12:45 PM, Steve Mills <sjmi...@mac.com> wrote: I'm working on a project that's had to support older hardware/software until now, so we can *finally* convert to ARC. Since it's been almost a year since I've worked on anything that used ARC, I'm a little rusty o

Converting to ARC and blocks

I'm working on a project that's had to support older hardware/software until now, so we can *finally* convert to ARC. Since it's been almost a year since I've worked on anything that used ARC, I'm a little rusty on some of the stranger stuff, like __unsafe_retained. Here's a pared down hunk

Re: ARC code in a non ARC app. iOS

On 24 Feb 2016, at 00:25, Alex Zavatone <z...@mac.com> 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 p

Re: ARC code in a non ARC app. iOS

don’t remember what the conventions are, it’s easy to go wrong in MMR. Interestingly, in the old days, people argued about whether to do [[NSArray alloc] init] or [NSArray array], based on clarity vs. efficiency (avoidance of an autorelease). As soon as ARC took charge, no one cared any more,

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

Re: ARC code in a non ARC app. iOS

> On 25 Feb 2016, at 17:43, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Feb 25, 2016, at 8:35 AM, Dave <d...@looktowindward.com >> <mailto:d...@looktowindward.com>> wrote: >> >>>> Also, beware subclassing a Non-ARC Class in an ARC

Re: ARC code in a non ARC app. iOS

> On Feb 25, 2016, at 8:35 AM, Dave <d...@looktowindward.com> 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

Re: ARC code in a non ARC app. iOS

> On 24 Feb 2016, at 23:57, Greg Parker <gpar...@apple.com> wrote: > > >> On Feb 24, 2016, at 2:31 AM, Dave <d...@looktowindward.com> wrote: >> >> Also, beware subclassing a Non-ARC Class in an ARC Project - you have to >> have the subclass No

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

Re: ARC code in a non ARC app. iOS

> On Feb 24, 2016, at 2:31 AM, Dave <d...@looktowindward.com> 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.

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

Re: ARC code in a non ARC app. iOS

;> >> 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 releases, so >

Re: ARC code in a non ARC app. iOS

> On Feb 23, 2016, at 3:46 PM, Alex Zavatone <z...@mac.com> 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 t

Re: ARC code in a non ARC app. iOS

On Feb 23, 2016, at 15:25 , Alex Zavatone <z...@mac.com> 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

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 <gpar...@apple.com> wrote: > > >> On Feb 23, 2

Re: ARC code in a non ARC app. iOS

> On Feb 23, 2016, at 3:25 PM, Alex Zavatone <z...@mac.com> 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 dy

Re: ARC code in a non ARC app. iOS

tomorrow morn. Is that well advised TY Mr. Q. Cheers, AZAVATON Sent from my iPhone > On Feb 23, 2016, at 6:19 PM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> On Feb 23, 2016, at 13:30 , Alex Zavatone <z...@mac.com> wrote: >> >> N

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

Re: ARC code in a non ARC app. iOS

On Feb 23, 2016, at 13:30 , Alex Zavatone <z...@mac.com> 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-an

Re: ARC code in a non ARC app. iOS

> On Feb 23, 2016, at 1:30 PM, Alex Zavatone <z...@mac.com> 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

ARC code in a non ARC app. iOS

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 than ours. The intent is to run as a little service that can

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,

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

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

g 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 it appeared as if I did not need to nil out the > reference at dealloc (this makes sense) but is it an on purpose behaviour > th

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

Hi All, This is for Mac, not iOS. Under ARC, should an IBOutlet be strong or weak? If strong, do I need to set the outlets to nil in the corresponding dealloc method? I did a google for this and are many conflicting answers to this question but one with a lot of votes on Stack Overflow

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

this and it appeared as if I did not need to nil out the reference at dealloc (this makes sense) but is it an on purpose behaviour that is supported by the ARC implementation or is it some side effect that may go away? Most likely the former, but who likes to leave potential down the road a** biters

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

Re: ARC, blocks, capture variables

er does not catch it, and I'd be right back where I was before ARC--everything working OK. And you can also assign to a weak local var & then use that, not create a retain cycle, and not have to break it anymore. And you can wrap that in a macro something like: #define WeakRef(s) __weak

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

  1   2   3   4   5   6   7   8   >