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

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 of an NSWindo

Re: Converting to ARC and blocks

> On May 2, 2016, at 11:30 AM, Steve Mills wrote: > > On May 02, 2016, at 12:58 PM, John McCall wrote: > > > You don't have to declare something with __block just to use it in a block. > > __block specifically means that the variable will be captured *by > > reference* in the block, meaning t

Re: Converting to ARC and blocks

On May 02, 2016, at 12:58 PM, John McCall wrote: You don't have to declare something with __block just to use it in a block. __block specifically means that the variable will be captured *by reference* in the block, meaning that changes to the variable within the block are visible in the orig

Re: Converting to ARC and blocks

> On May 2, 2016, at 10:38 AM, Steve Mills 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 on some of the > stranger s

Re: Converting to ARC and blocks

On May 02, 2016, at 12:45 PM, Steve Mills 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 on some of the stranger stuff, l

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 bef

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

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

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

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 Managemen

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

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

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]; &

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 > <mailto:d...@looktowindward.com>> wrote: >> >> Hi, >> >> Has anyone come up with a way of having the source code support both ARC and >> Manual Me

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 l

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

ARC and Manual Memory Management

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 release]; If it’s being compiled for ARC, that way both could

Re: ARC and NSObjectController bindings through file's owner

On Aug 1, 2014, at 12:03 , Jerry Krinock wrote: > Unfortunately, I’m not able to justify my design pattern based on the Cocoa > Bindings API documentation. As I said earlier in the thread, that fact that the error messages go away doesn’t mean the problem doesn’t exist. However, I think you’re

Re: ARC and NSObjectController bindings through file's owner

On 2014 Aug 01, at 10:33, Sean McBride wrote: > I've tried some similar permutations and they have 'fixed' the issue. I have > about 50 xibs to fix now, so want to be sure I do this correctly. :) I now > find myself questioning basic things. :) I understand. It would be nice to have to hav

Re: ARC and NSObjectController bindings through file's owner

On Aug 1, 2014, at 10:33 AM, Sean McBride wrote: > > On Thu, 31 Jul 2014 09:26:27 -0700, Jerry Krinock said: > >>> One thing I just noticed is that NSWindowController's 'document' >> property is not actually documented as KVO-compliant. Maybe that's my >> problem... but I've been binding throug

Re: ARC and NSObjectController bindings through file's owner

On Thu, 31 Jul 2014 09:26:27 -0700, Jerry Krinock said: >> One thing I just noticed is that NSWindowController's 'document' >property is not actually documented as KVO-compliant. Maybe that's my >problem... but I've been binding through it for over a decade now! > >That may well be the real probl

Re: ARC and NSObjectController bindings through file's owner

On Jul 31, 2014, at 09:05 , Sean McBride wrote: > Other than use of 'weak', how else might something be changed in a > non-KVO-compliant manner in ARC but not GC? Again, the error is only in ARC > and not GC. I’m not sure this is the most productive way to approach this. T

Re: ARC and NSObjectController bindings through file's owner

On 2014 Jul 31, at 09:05, Sean McBride wrote: > One thing I just noticed is that NSWindowController's 'document' property is > not actually documented as KVO-compliant. Maybe that's my problem... but > I've been binding through it for over a decade now! That may well be the real problem, Sea

Re: ARC and NSObjectController bindings through file's owner

weak? >Likewise, if any other property along that key path is changed in a non- >KVO-compliant manner, that would lead to the same sort of error. Other than use of 'weak', how else might something be changed in a non-KVO-compliant manner in ARC but not GC? Again, t

Re: ARC and NSObjectController bindings through file's owner

On Jul 30, 2014, at 13:33 , Sean McBride wrote: > File's Owner (my NSViewController subclass) responds to 'windowController' > because I have a vanilla synthesized weak property relating my > NSViewController to its containing window's controller. This is the problem. Weak properties aren’t KV

Re: ARC and NSObjectController bindings through file's owner

On Jul 30, 2014, at 3:33 PM, Sean McBride wrote: > I'm slowing moving my GC app to ARC. One runtime error I'm stuck at is: > > > An instance 0x10f587510 of class MyDocument was deallocated while key value > observers were still registered with it. > > document.managedObjectContext,

ARC and NSObjectController bindings through file's owner

Hi all, I'm slowing moving my GC app to ARC. One runtime error I'm stuck at is: An instance 0x10f587510 of class MyDocument was deallocated while key value observers were still registered with it. Context: 0x0, Property: 0x10ee1ac10> I have: - a nib who's File's Owner is

Re: ARC and autorelease pools

Thanks to Marcel, John McCall, and Clark Smith Cox III for addressing the question I was trying to ask, apologies to others that the question was unclear. So it seems that because ARC provides compatibility between ARC and non-ARC code unlike how garbage collection worked with duplicated

Re: ARC and autorelease pools

equire 2 versions of every framework, but instead provide compatibility between ARC and non-ARC code. Therefore all the old requirements for autorelease, which have been explained so well by various posters, apply. Cheers, Marcel ___ Cocoa-d

Re: ARC and autorelease pools

lishly assumed they did because a modified version of autorelease was > kept with the transition to ARC and my most common experience of dealing with > autoreleased objects was via the behaviour of the class methods that create > objects. So yes a foolish assumption on my behalf. > >>&g

Re: ARC and autorelease pools

On Feb 16, 2014, at 1:03 PM, Jens Alfke wrote: > On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote: > >> I didn't say take them out. I said why do they need to return an >> autoreleased object. Why can't they just return an object like alloc init... >> does. > > Because if they returned an obj

Re: ARC and autorelease pools

And would be just like every other manual reference-counting scheme, with all of the additional code they entail, and the higher liklihood of bugs, and so on... On Feb 16, 2014, at 2:13 PM, Jens Alfke wrote: > The only way to resolve this without autorelease would be to enforce that > _all_ m

Re: ARC and autorelease pools

On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote: > You're missing the question I was trying to ask. Why is autorelease needed at > all? It's needed when a method creates an object [or otherwise gets an object with a reference that needs to be released] and has to return that object, but the

Re: ARC and autorelease pools

On Feb 16, 2014, at 10:22 AM, Kevin Meaney wrote: > I didn't say take them out. I said why do they need to return an autoreleased > object. Why can't they just return an object like alloc init... does. Because if they returned an object that wasn't autoreleased (i.e. that the caller needs to

Re: ARC and autorelease pools

ishly assumed they did because a modified version of autorelease was kept with the transition to ARC and my most common experience of dealing with autoreleased objects was via the behaviour of the class methods that create objects. So yes a foolish assumption on my behalf. >> It seems t

Re: ARC and autorelease pools

On Feb 16, 2014, at 5:27 AM, Kevin Meaney wrote: > Is the only reason for interoperability with manual retain-release code? For backward compatibility. Nearly every piece of existing Cocoa code uses these methods, so there's no way they could take them out. > It seems that it creates an unnec

Re: ARC and autorelease pools

On Feb 16, 2014, at 7:27 AM, Kevin Meaney wrote: > Why do these methods need to return an autoreleased object, why can't they > behave the same as: > > NSString *myString = [[NSString alloc] initWithFormat:@"%@", @"my String]; > > Is the only reason for interoperability with manual retain-rele

Re: ARC and autorelease pools

On 16 Feb, 2014, at 9:27 pm, Kevin Meaney wrote: > I've realized that my understanding of ARC is not as good as I thought it > was. So I'll be asking couple of questions. > > With ARC I don't understand why autorelease pools are needed anymore except > for with objects passed by reference. Wh

ARC and autorelease pools

nd the ones outside of those frameworks. I've read a couple of posts on stackoverflow in relation to ARC and autorelease, but the justification given in the answers as to why autorelease is needed is because there are methods that return autoreleased objects so we need to have a mechanism t

Re: PDFDocument, ARC and 10.9 question

> Your problem is likely well before that point, since it looks like the > failure has to do with a font. Either the font is damaged somehow, or the > reference is invalid. OK, this is really weird. It works well in a compiled app, it works well running all different tests under Instruments,

Re: PDFDocument, ARC and 10.9 question

17 jan 2014 kl. 18:43 skrev David Duncan : > Your problem is likely well before that point, since it looks like the > failure has to do with a font. Either the font is damaged somehow, or the > reference is invalid. I thought so too, and the fact that running the app from Instruments has no p

Re: PDFDocument, ARC and 10.9 question

Your problem is likely well before that point, since it looks like the failure has to do with a font. Either the font is damaged somehow, or the reference is invalid. On Jan 17, 2014, at 4:22 AM, Totte Alm wrote: > Hello again, > > Still debugging my CG -> ARC move and I'm stuck with one prob

PDFDocument, ARC and 10.9 question

Hello again, Still debugging my CG -> ARC move and I'm stuck with one problem that I just can't understand. DEBUG SNIP WHERE THIS HAPPENS _thePDF = [[PDFDocument alloc] initWithData:_data]; // test- if (_thePDF) { @try { *CRASHES HERE* -> [_thePDF writeToFile:[NS

Re: ARC and NSError output parameters: proper declaration?

On Oct 7, 2013, at 1:44 PM, Sean McBride wrote: > Hi all, > > I understand the issue with NSError output parameters and ARC, and that it > automatically 'adds' an __autoreleasing, but I'm wondering what is the > recommended way to declare NSError output par

ARC and NSError output parameters: proper declaration?

Hi all, I understand the issue with NSError output parameters and ARC, and that it automatically 'adds' an __autoreleasing, but I'm wondering what is the recommended way to declare NSError output parameters in new code these days: 1) No decorations, ex: - (BOOL)foobar:(NSEr

Re: Arc and **

On Dec 4, 2012, at 10:44 PM, Gerriet M. Denkmann wrote: > On 5 Dec 2012, at 12:59, Greg Parker wrote: >> On Dec 4, 2012, at 8:56 PM, Gerriet M. Denkmann wrote: >>> I have (using Arc) a method which works fine: >>> NSString *explanation; >>> [ self doSomeThingAndExplain: &explanation ]; >>> >>>

Re: Arc and **

On 5 Dec 2012, at 12:59, Greg Parker wrote: > On Dec 4, 2012, at 8:56 PM, Gerriet M. Denkmann wrote: >> I have (using Arc) a method which works fine: >> NSString *explanation; >> [ self doSomeThingAndExplain: &explanation ]; >> >> Now I decided that sometimes I don't need this explanation. So

Re: Arc and **

On Dec 4, 2012, at 8:56 PM, Gerriet M. Denkmann wrote: > I have (using Arc) a method which works fine: > NSString *explanation; > [ self doSomeThingAndExplain: &explanation ]; > > Now I decided that sometimes I don't need this explanation. So I changed it > to: > > NSString **explanatioP = urge

Re: Arc and **

NSString *explanation; [ self doSomeThingAndExplain:( urgent ? NULL : &explanation ) ]; I tried some REALLY ugly casts putting __autoreleasing and __strong here and there around the *s in the explainP but got nowhere, so that's the best I can come up with apart from writing doSomethingAndDontExp

Arc and **

I have (using Arc) a method which works fine: NSString *explanation; [ self doSomeThingAndExplain: &explanation ]; Now I decided that sometimes I don't need this explanation. So I changed it to: NSString **explanatioP = urgent ? NULL : &explanation; // <-- "no explicit ownership... [ self doSome

Re: NSMapTable thread safety (with with ARC and weak objects)

On 19 nov 2012, at 04:05, James Montgomerie wrote: > On 16 Nov 2012, at 22:36, Quincey Morris > wrote: > >> On Nov 16, 2012, at 09:53 , James Montgomerie wrote: >>> Let's assume I'm using ARC. If I create an NSMapTable with "[NSMapTable >>> strongToWeakObjectsMapTable]", is it safe to put

Re: NSMapTable thread safety (with with ARC and weak objects)

On 16 Nov 2012, at 22:36, Quincey Morris wrote: > On Nov 16, 2012, at 09:53 , James Montgomerie wrote: >> Let's assume I'm using ARC. If I create an NSMapTable with "[NSMapTable >> strongToWeakObjectsMapTable]", is it safe to put objects into it that might >> be referenced from, and perhaps

Re: NSMapTable thread safety (with with ARC and weak objects)

On Nov 16, 2012, at 09:53 , James Montgomerie wrote: > How thread safe is NSMapTable? > > I know that's a pretty nebulous question, so more concretely: > > Let's assume I'm using ARC. If I create an NSMapTable with "[NSMapTable > strongToWeakObjectsMapTable]", is it safe to put objects into i

NSMapTable thread safety (with with ARC and weak objects)

How thread safe is NSMapTable? I know that's a pretty nebulous question, so more concretely: Let's assume I'm using ARC. If I create an NSMapTable with "[NSMapTable strongToWeakObjectsMapTable]", is it safe to put objects into it that might be referenced from, and perhaps deallocated on, a bac

Re: Custom UITableView cell label with ARC and storyboards

Thanks. I moved the resizing of the frame in a method in the custom cell class instead of in the TVC's cellForRowAtIndexPath. What is strange is that I call it from the TVC's cellForRowAtIndexPath and it works just fine, but didn't do anything when in the TVC's cellForRowAtIndexPath. Not exac

Re: Custom UITableView cell label with ARC and storyboards

On Jul 29, 2012, at 7:55 PM, Alex Zavatone wrote: > > On Jul 29, 2012, at 10:48 PM, David Duncan wrote: > >> On Jul 29, 2012, at 7:38 PM, Alex Zavatone wrote: >> >>> >>> On Jul 29, 2012, at 10:30 PM, David Duncan wrote: >>> On Jul 29, 2012, at 7:02 PM, Alex Zavatone wrote:

Re: Custom UITableView cell label with ARC and storyboards

On Jul 29, 2012, at 10:48 PM, David Duncan wrote: > On Jul 29, 2012, at 7:38 PM, Alex Zavatone wrote: > >> >> On Jul 29, 2012, at 10:30 PM, David Duncan wrote: >> >>> On Jul 29, 2012, at 7:02 PM, Alex Zavatone wrote: >>> I've put together a TVC with a custom TVC cell class consisting m

Re: Custom UITableView cell label with ARC and storyboards

On Jul 29, 2012, at 7:38 PM, Alex Zavatone wrote: > > On Jul 29, 2012, at 10:30 PM, David Duncan wrote: > >> On Jul 29, 2012, at 7:02 PM, Alex Zavatone wrote: >> >>> I've put together a TVC with a custom TVC cell class consisting mainly of >>> UILabels, but have the problem where the labels

Re: Custom UITableView cell label with ARC and storyboards

On Jul 29, 2012, at 10:30 PM, David Duncan wrote: > On Jul 29, 2012, at 7:02 PM, Alex Zavatone wrote: > >> I've put together a TVC with a custom TVC cell class consisting mainly of >> UILabels, but have the problem where the labels will have varying amounts of >> lines of text. >> >> The mai

Re: Custom UITableView cell label with ARC and storyboards

On Jul 29, 2012, at 7:02 PM, Alex Zavatone wrote: > I've put together a TVC with a custom TVC cell class consisting mainly of > UILabels, but have the problem where the labels will have varying amounts of > lines of text. > > The main issue is that in iOS 5.x, UILabels still can't be verticall

Custom UITableView cell label with ARC and storyboards

I've put together a TVC with a custom TVC cell class consisting mainly of UILabels, but have the problem where the labels will have varying amounts of lines of text. The main issue is that in iOS 5.x, UILabels still can't be vertically aligned to the top. There is a fair amount of source tha

Re: ARC and reinterpret_cast

On Jul 18, 2012, at 1:22 , Jean-Daniel Dupas wrote: > Just a though, but isn't it possible to define yourself a template function > to do that ? > > something like > > template > static inline C bridge_cast(void *ptr) { return (__bridge C)ptr; } Hey, that's kinda cool! I think that might w

Re: ARC and reinterpret_cast

Le 18 juil. 2012 à 08:28, Rick Mann a écrit : > > On Jul 9, 2012, at 16:00 , John McCall wrote: > >>>>> From: Rick Mann >>>>> Subject: ARC and reinterpret_cast? >>>>> Date: July 7, 2012 9:13:29 PM PDT >>>>>

Re: ARC and reinterpret_cast

On Jul 9, 2012, at 16:00 , John McCall wrote: >>>> From: Rick Mann >>>> Subject: ARC and reinterpret_cast? >>>> Date: July 7, 2012 9:13:29 PM PDT >>>> To: Cocoa-Dev List >>>> >>>> Hi. I'd like to write cod

Re: ARC and reinterpret_cast

>>> From: Rick Mann >>> Subject: ARC and reinterpret_cast? >>> Date: July 7, 2012 9:13:29 PM PDT >>> To: Cocoa-Dev List >>> >>> Hi. I'd like to write code like this: >>> >>> MyObject* foo = reinterpret_cast<

Re: ARC and reinterpret_cast?

On 08.07.2012, at 06:13, Rick Mann wrote: > Hi. I'd like to write code like this: > > MyObject* foo = reinterpret_cast<__bridge MyObject*> (someVoidPointer); > > But the compiler doesn't like it. It's perfectly happy with: > > MyObject* foo = (__bridge MyObject) someVoidPointer; >

ARC and reinterpret_cast?

Hi. I'd like to write code like this: MyObject* foo = reinterpret_cast<__bridge MyObject*> (someVoidPointer); But the compiler doesn't like it. It's perfectly happy with: MyObject* foo = (__bridge MyObject) someVoidPointer; this is in a .mm file. The error is: error: type name

Re: ARC and CFType release callback

FAutorelease(CGColorCreateWithPattern(...)); > > But this code isn't safe under ARC is it? I would think that since > they're CFTypes, they're invisible to ARC and can be deallocated > early. Correct, that's unsafe. ARC won't retain it because ther

Re: ARC and CFType release callback

} and use code that looks like: CGPatternRef pattern = MyCFAutorelease(CGPatternCreate(...)); CGColorRef color = MyCFAutorelease(CGColorCreateWithPattern(...)); But this code isn't safe under ARC is it? I would think that since they're CFTypes, they're invisible to AR

Re: ARC and CFType release callback

On Jun 19, 2012, at 8:58 PM, Dave Keck wrote: > Greg Parker wrote: >> Clean up the void* context with CFRelease(context) or (ObjectType >> *)CFBridgingRelease(context) > > I see -- I was under the impression that CFBridgingRetain/Release was > meant for converting to/from CFTypes rather than arb

Re: ARC and CFType release callback

>    Clean up the void* context with CFRelease(context) or (ObjectType > *)CFBridgingRelease(context) I see -- I was under the impression that CFBridgingRetain/Release was meant for converting to/from CFTypes rather than arbitrary pointers, but it works as expected. Thanks! David _

Re: ARC and CFType release callback

On Jun 19, 2012, at 8:28 PM, Dave Keck wrote: > I have a CFType (specifically a CGPattern) that uses a release > callback to free resources, and the void* pointer passed to the > callback is the object to be released. > > What's the correct way to release this void* pointer (that's really an > NS

ARC and CFType release callback

I have a CFType (specifically a CGPattern) that uses a release callback to free resources, and the void* pointer passed to the callback is the object to be released. What's the correct way to release this void* pointer (that's really an NSObject subclass) under ARC? Casting it using __bridge_trans

Re: Arc and autorelease

On May 24, 2012, at 1:14 AM, Gerriet M. Denkmann wrote: > Without Arc, this: > > NSString *s = [ [ NSString alloc ] initWithFormat: ...]; > [ someCollection addObject: s ]; > [ s release ]; > > is clearly more efficient (because not using autoreleasepools) than: > > NSString *s = [ NSString str

Re: Arc and autorelease

On May 24, 2012, at 3:14 AM, Gerriet M. Denkmann wrote: > Without Arc, this: > > NSString *s = [ [ NSString alloc ] initWithFormat: ...]; > [ someCollection addObject: s ]; > [ s release ]; > > is clearly more efficient (because not using autoreleasepools) than: > > NSString *s = [ NSString str

Arc and autorelease

Without Arc, this: NSString *s = [ [ NSString alloc ] initWithFormat: ...]; [ someCollection addObject: s ]; [ s release ]; is clearly more efficient (because not using autoreleasepools) than: NSString *s = [ NSString stringWithFormat: ...]; [ someCollection addObject: s ]; But what about Arc?

ARC and static functions, free functions and C++ member functions

I would like to define a static function which returns a newly created object, for example: static Foo* makeFoo(const char* arg) { return [[Foo alloc] initWithArg:arg]; } Do I need to use __attribute__((ns_returns_retained)), or is the above definition already correct as it is? Furthermor

Re: ARC and 10.6

>> I try to convert my app to use xCode 4.2 and ARC. My app uses several custom >> frameworks and plugins. I used the migration tool to enable ARC for all of >> them. >> >> As I still want to support Snow Leopard, I set the SDKROOT to 10.7 and the >> Deployment Target to 10.6. But if I do that,

Re: ARC and 10.6

Me again. I fixed it. I forgot to specify a Principle class for some of my plugins. This was no problem before, not with gcc (xCode 3) and not with clang in xCode 4. Thanks Georg On 03.02.2012, at 00:24, Greg Parker wrote: > On Feb 2, 2012, at 2:51 PM, Georg Seifert wrote: >> I try to conver

Re: ARC and 10.6

On 03.02.2012, at 00:24, Greg Parker wrote: > On Feb 2, 2012, at 2:51 PM, Georg Seifert wrote: >> I try to convert my app to use xCode 4.2 and ARC. My app uses several custom >> frameworks and plugins. I used the migration tool to enable ARC for all of >> them. >> >> As I still want to support

Re: ARC and 10.6

On Feb 2, 2012, at 2:51 PM, Georg Seifert wrote: > I try to convert my app to use xCode 4.2 and ARC. My app uses several custom > frameworks and plugins. I used the migration tool to enable ARC for all of > them. > > As I still want to support Snow Leopard, I set the SDKROOT to 10.7 and the >

ARC and 10.6

Hi, I try to convert my app to use xCode 4.2 and ARC. My app uses several custom frameworks and plugins. I used the migration tool to enable ARC for all of them. As I still want to support Snow Leopard, I set the SDKROOT to 10.7 and the Deployment Target to 10.6. But if I do that, on the startu

Re: ARC and blocks

release. There's no retain cycle or >> memory leak, and the __block variable is guaranteed to stick around until >> your block is done with it. >> > > Yes - that __unsafe_unretained pattern is in the transition guide, but it's > not recommended and seems t

Re: ARC and blocks

> is done with it. > Yes - that __unsafe_unretained pattern is in the transition guide, but it's not recommended and seems to be there more for illustration of what pre-ARC code was equivalent to. Just setting the __block variable nil will work fine under ARC and pre-ARC runtimes so,

Re: ARC and blocks

On Jan 26, 2012, at 6:04 PM, Marco Tabini wrote: > On 2012-01-26, at 6:09 PM, Jeff Kelley wrote: >> Without ARC, you would use __block to prevent the block from retaining the >> object and causing the retain cycle. With ARC, however, the object is >> retained when you put it into the variable, so

  1   2   >