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 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 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 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. The detection of an

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

On Wed, 30 Jul 2014 15:45:04 -0500, Ken Thomases said: >A zeroing weak property changes without emitting KVO change >notifications. Therefore, it's not KVO-compliant. Basically, weak >properties are incompatible with KVO and bindings. Ouch! Didn't realise that. That's pretty annoying, as weak

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,

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 framewo

Re: ARC and autorelease pools

On Feb 17, 2014, at 2:08 , Clark Smith Cox III wrote: >> I didn't say take them out. I said why do they need to return an >> autoreleased object. > > Because they always have, and their semantics cannot be changed without > breaking decades worth of non-ARC code. Sort of like the way GC did,

Re: ARC and autorelease pools

On Feb 16, 2014, at 10:22, Kevin Meaney wrote: > > On 16 Feb 2014, at 17:06, Jens Alfke wrote: > >> 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 exist

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

On 16 Feb 2014, at 17:06, Jens Alfke wrote: > 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

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

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 parameters in new code these days: > >

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

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 > To: Cocoa-Dev List > > Hi. I'd like to write code like this: > >

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 code like this: MyObject* foo = reinterpret_cast<__bridge MyObject*> (someVoid

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<__bridge MyObject*> (someVoidPointer); >>> >>> But the compiler doesn't like it. It

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

Re: ARC and CFType release callback

On Jun 19, 2012, at 10:19 PM, Dave Keck wrote: >> Once you have a CFTypeRef via CFBridgingRetain(), ARC doesn't care what you >> do with it. Convert it to and from uintptr_t, pass it through a void*, send >> it around via IPC, whatever. > > That makes sense. I'm also looking for a pattern simi

Re: ARC and CFType release callback

> Once you have a CFTypeRef via CFBridgingRetain(), ARC doesn't care what you > do with it. Convert it to and from uintptr_t, pass it through a void*, send > it around via IPC, whatever. That makes sense. I'm also looking for a pattern similar to this RR code, so that I can leave out explicit CF

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

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

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 >

Re: ARC and blocks

On Jan 26, 2012, at 10:45 PM, Roland King wrote: > > On Jan 27, 2012, at 10:04 AM, 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

Re: ARC and blocks

On Jan 27, 2012, at 10:04 AM, 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 variab

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

Re: ARC and blocks

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 to avoid a retain cycle, you > have to declare it l

Re: ARC and blocks

On Jan 27, 2012, at 6:44 AM, Conrad Shultz wrote: > On 1/26/12 1:51 PM, Jan E. Schotsman wrote: >> >> > > The block normally would retain variables it captures from its scope, > including, in this case, myController. Presumably myController would > retain the completionHandler block, ergo a r

Re: ARC and blocks

Hi, > So, when myController is nil'ed out, ARC releases it, and it releases > the block in turn. No leaks/abandoned memory. > > A special form of this is the idiom: > > __block id mySelf = self; > > ^{ > [mySelf doSomething]; > } Wouldn't using __weak instead of __block be better and cleare

Re: ARC and blocks

On 1/26/12 4:21 PM, Kyle Sluder wrote: > On Thu, Jan 26, 2012 at 2:44 PM, Conrad Shultz > wrote: >> However, __block variables are NOT retained automatically by a block >> during capture, so this breaks the retain cycle. > > __block variables *are* retained under ARC: > http://clang.llvm.org/docs

Re: ARC and blocks

On Thu, Jan 26, 2012 at 2:44 PM, Conrad Shultz wrote: > However, __block variables are NOT retained automatically by a block > during capture, so this breaks the retain cycle. __block variables *are* retained under ARC: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#misc.blocks The i

Re: ARC and blocks

On Jan 26, 2012, at 2:44 PM, Conrad Shultz wrote: > However, __block variables are NOT retained automatically by a block > during capture, so this breaks the retain cycle. This is not true under ARC, where __block variables also retain. -- David Duncan __

Re: ARC and blocks

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 to avoid a retain cycle, you have to declare it like so: __unsafe_unretained __block MyViewCont

Re: ARC and blocks

On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote: > This code is given in the "Transitioning to ARC Release Notes" as an example > of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; > // ... > myController.completionHand

Re: ARC and blocks

On Jan 26, 2012, at 3:51 PM, Jan E. Schotsman wrote: > This code is given in the "Transitioning to ARC Release Notes" as an example > of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; > // ... > myController.completionHan

Re: ARC and blocks

On 2012-01-26, at 3:51 PM, Jan E. Schotsman wrote: > Hello, > > This code is given in the "Transitioning to ARC Release Notes" as an example > of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; > // ... > myController.com

Re: ARC and blocks

On 26 Jan 2012, at 3:51 PM, Jan E. Schotsman wrote: > This code is given in the "Transitioning to ARC Release Notes" as an example > of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; There is a MyViewController object n

Re: ARC and blocks

On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote: > Supposedly this avoids a retain cycle. But where is the cycle? At least two > objects are needed for a cycle. What is the second one? The block. When a block is copied (which it has to be, in order to be called later after the calling func

Re: ARC and blocks

On 1/26/12 1:51 PM, Jan E. Schotsman wrote: > Hello, > > This code is given in the "Transitioning to ARC Release Notes" as an > example of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; > // ... > myController.completionHa

Re: ARC and blocks

Le 26 janv. 2012 à 22:51, Jan E. Schotsman a écrit : > Hello, > > This code is given in the "Transitioning to ARC Release Notes" as an example > of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; > // ... > myController.

Re: ARC and blocks

On Jan 26, 2012, at 1:51 PM, Jan E. Schotsman wrote: > Hello, > > This code is given in the "Transitioning to ARC Release Notes" as an example > of accomodating blocks in an ARC environment: > > __block MyViewController *myController = [[MyViewController alloc] init…]; > // ... > myController.c

Re: ARC and dealloc

On Thu, 08 Dec 2011 20:31:51 +0100, Mikkel Islay said: >A twist on the tale, is that the observer wasn't the UIViewController, but a >helper object subclassed from NSObject. Hence view-unloading was one step >further removed from deallocation of the observer-instance. I have *never* added or

Re: ARC and dealloc

Thanks for the insightful reply, and of course to Jonny Yu and Scott Anguish as well. On 8 Dec 2011, at 17:36, Matt Neuburg wrote: >> You can certainly make assumptions about when dealloc is called - it is >> extremely deterministic, actually. See Greg Parker's discussion (in the WWDC >> 2011

Re: ARC and dealloc

On Wed, 07 Dec 2011 21:56:56 +0100, Mikkel Islay said: >Dear list, > >A question regarding the proper use of dealloc in ARC-environments (under iOS): >I have a need to unregister NSNotification observers during exchange of >UiViewControllers. Is implementing - (void)dealloc considered a proper u

Re: ARC and dealloc

My understanding is, due to auto release semantics, your object might be auto released again during current pool draining. So it will be put into outer Autorelease Pool, that's to say the dealloc are not guaranteed to be executed at specific timing. ARC still relies on retain/release/autorelease

Re: ARC and NSNib: How to release top-level objects?

On Fri, Nov 18, 2011 at 1:47 PM, Charles Srstka wrote: > How is one supposed to manage this? You can easily get the array of the > top-level objects, but since ARC doesn’t let you send -release to them, it > doesn’t help much. The only ways I can think of to avoid leaking are to do > silly thin

Re: Arc and performSelector

On 18 Oct 2011, at 00:29, glenn andreas wrote: > > On Oct 16, 2011, at 1:58 AM, Gerriet M. Denkmann wrote: > >> I have this code: >> >> for( id aThing in someArray ) >> { >> if ( [ aThing respondsToSelector: @selector(setTitle:) ] ) >> { >> [ self replaceIn

Re: Arc and performSelector

On Oct 16, 2011, at 1:58 AM, Gerriet M. Denkmann wrote: > I have this code: > > for( id aThing in someArray ) > { > if ( [ aThing respondsToSelector: @selector(setTitle:) ] ) > { > [ self replaceIn: aThing > rea

Re: Arc and performSelector

On Oct 17, 2011, at 10:19 AM, Gerriet M. Denkmann wrote: > I understand this. So I tried to tell the compiler that the passed selector > is not like copy: > > - (void)replaceIn: thing readSelector: > (__attribute__((ns_returns_not_retained)) SEL)selectorIn > { > NSString *key = [ thing

Re: Arc and performSelector

On 18 Oct 2011, at 00:05, David Duncan wrote: > On Oct 15, 2011, at 11:58 PM, Gerriet M. Denkmann wrote: > >> I have this code: >> >> for( id aThing in someArray ) >> { >> if ( [ aThing respondsToSelector: @selector(setTitle:) ] ) >> { >> [ self replaceIn:

Re: Arc and performSelector

On Oct 15, 2011, at 11:58 PM, Gerriet M. Denkmann wrote: > I have this code: > > for( id aThing in someArray ) > { > if ( [ aThing respondsToSelector: @selector(setTitle:) ] ) > { > [ self replaceIn: aThing > rea

Re: Arc and performSelector

I think you understand why the warning is coming up. But I would suggest this is a factorisation too far. Do you need to employ this (to my eyes, rather strange) form of code so often that it is necessary to factor out the selector in/out code in the way you have? Why not just move the performS

Re: Arc and performSelector

On Oct 16, 2011, at 00:23 , Gerriet M. Denkmann wrote: > I have this code: > > for( id aThing in someArray ) > { > if ( [ aThing respondsToSelector: @selector(setTitle:) ] ) > { > [ self replaceIn: aThing > readS

Re: ARC and NSFastEnumeration

On Sep 19, 2011, at 3:33 AM, Devraj Mukherjee wrote: > I am trying to implement fast enumeration for a wrapper object that > has an NSArray, following this tutorial > http://cocoawithlove.com/2008/05/implementing-countbyenumeratingwithstat.html > > Obviously ARC doesn't like the way > > - (NSUInt

Re: ARC and NSFastEnumeration

If it has an NSArray, you don't have to follow that tutorial - NSArray already implements NSFastEnumeration, so your wrapper can simply call the same methods on NSArray. Job done. The tutorial is somewhat artificial in that it creates an object using a C array (and secondly a linked list) as it

Re: ARC and Singletons

Submitted as an enhancement request.. :) Bug ID# 9908437 bob.. On Aug 2, 2011, at 5:29 PM, Dave Zarzycki wrote: > Karl, > > This is not on our todo list or any list that I know of. Please file a bug > report if this enhancement request is interesting to you. > > Thanks! :-) > > davez > >

Re: ARC and Singletons

On Aug 3, 2011, at 2:29 AM, Dave Zarzycki wrote: > Karl, > > This is not on our todo list or any list that I know of. Please file a bug > report if this enhancement request is interesting to you. > > Thanks! :-) Oh, we need to file an enhancement request when we would like to have class vari

Re: ARC and Singletons

Karl, This is not on our todo list or any list that I know of. Please file a bug report if this enhancement request is interesting to you. Thanks! :-) davez On Aug 2, 2011, at 4:59 PM, Karl Goiser wrote: > Hi Greg, > > Is that wishful thinking or a hint about the future? > :-) > > > All I

  1   2   >