automatic-ref-counting

Do loops and convenience methods cause memory peaks with ARC?

…衆ロ難τιáo~ 提交于 2019-12-03 05:11:21
问题 I'm working with ARC and seeing some strange behavior when modifying strings in a loop. In my situation, I'm looping using NSXMLParser delegate callbacks, but I see the same exact behavior and symptoms using a demo project and sample code which simply modifies some NSString objects. You can download the demo project from GitHub, just uncomment one of the four method calls in the main view controller's viewDidLoad method to test the different behaviors. For simplicity's sake, here's a simple

How to force xcode to use ARC on a specific file?

余生颓废 提交于 2019-12-03 05:05:54
My project contains XMPPFramework which contains a file that has to be used with ARC. But my project is Non ARC and cannot be converted due to certain other libraries linked to it. How do I force the compiler to use ARC only on a certain class ? justin It is the inverse problem of this question . The difference is that you would use -fobjc-arc instead of -fno-objc-arc . 来源: https://stackoverflow.com/questions/13392521/how-to-force-xcode-to-use-arc-on-a-specific-file

Container UIViewController Not Releasing it's Child View Controllers

余生颓废 提交于 2019-12-03 04:27:07
问题 I have a custom container UIViewController that has six child UIViewControllers, and a set of tabs that the user interacts with to switch between the child view controllers. The problem is when my container view controller is released the child view controllers are not. I have verified that the child view controllers are not released by adding some debugging code to their dealloc methods, and they are released as long as their view's are not added to the container view controller's view.

How to properly address “Weak receiver may be unpredictably null in ARC mode”

放肆的年华 提交于 2019-12-03 04:22:36
问题 I turned on a new flag in xcode and get the warning "Weak receiver may be unpredictably null in ARC mode". This confuses me because OF COURSE it could be nil. 回答1: I asked this question a week ago and received no answer, but Greg Parker answered it on the mailing list. So I am reposting with the answer. We added this warning because we saw lots of subtle and hard to debug problems in practice. The recommended practice is to read the weak variable into a strong local variable once, and then

iOS bridge vs bridge_transfer

假装没事ソ 提交于 2019-12-03 04:14:14
问题 I'm confused with bridge and bridge_transfer , is this correct? -(void)getData{ ABAddressBookRef addressBook = ABAddressBookCreate(); NSArray *allPeople = (__bridge_transfer NSArray*)ABAddressBookCopyArrayOfAllPeople(addressBook); NSString *name; for ( int i = 0; i < [allPeople count]; i++ ) { name = (__bridge_transfer NSString *) ABRecordCopyValue((__bridge ABRecordRef)[allPeople objectAtIndex:i], kABPersonFirstNameProperty); } CFRelease(addressBook); allPeople = nil; } Is there anyone who

Weak and strong properties in -viewDidUnload under ARC

淺唱寂寞╮ 提交于 2019-12-03 03:34:27
I am new to iphone development . I am using ARC for my project. As far as I understood using ARC we don't have to release any object manually. But , I have observed in some places , people explicitly set their object to nil in the ViewDidUnload even after using ARC. For example, in .h file I have something like this: @property (unsafe_unretained, nonatomic) IBOutlet MKMapView *mapViewOutlet; @property (unsafe_unretained, nonatomic) IBOutlet UIToolbar *toolBar; @property (strong,nonatomic) NSMutableArray *dataArray; And .m as follows: - (void)viewDidUnload { [self setMapViewOutlet:nil]; [self

Are there any concrete study of the performance impact of using ARC?

你。 提交于 2019-12-03 03:17:43
I could not find an objective study regarding ARC performance impact in a real life project. The official doc says The compiler efficiently eliminates many extraneous retain/release calls and much effort has been invested in speeding up the Objective-C runtime in general. In particular, the common “return a retain/autoreleased object” pattern is much faster and does not actually put the object into the autorelease pool, when the caller of the method is ARC code. which has been relayed/deformed by tech-fanboys into "ARC is faster". What I know for sure is what I measured. We recently migrated

ARC, self and blocks

前提是你 提交于 2019-12-03 03:11:50
I thought I understood the usage of self in a block that is copied is a no no . But in an attempt to clean my code i enabled a bunch of warnings in Xcode, one called "Sending messages to weak pointers" so now in all my blocks, every time I use my created weakself reference __weak typeof(self) weakself = self; I get this warning: Weak receiver may be unpredictably set to nil a trivial example: __weak typeof(self) weakself = self; [aClass doSomethingInABlock:^{ [weakself doSomething]; //warning. }]; I have seen answers which define a version of self within the block like so: __weak typeof(self)

strong @property with __attribute__((NSObject)) for a CF type doesn't retain

不打扰是莪最后的温柔 提交于 2019-12-03 02:24:22
问题 UPDATE: This issue has been fixed as of Xcode 4.6! This technique now works as intended again. However, make sure to read the notes at the top of Rob Napier's excellent answer before you use it in your code. ORIGINAL POST (ARC, Xcode 4.3.1, iOS 5.1) I have a strong property of a CF type (CGImage) that I want to be automatically managed by ARC using __attribute__((NSObject)) (as in having retain & release in the synthesized setter, and it being nil'ed in dealloc), but it doesn't work: the

implicit conversion of an Objective-C pointer to 'void *' is disallowed with ARC

吃可爱长大的小学妹 提交于 2019-12-03 02:18:14
问题 What does this mean and what alternative do I have? implicit conversion of an Objective-C pointer to 'void *' is disallowed with ARC I am porting an Xcode3 project to iOS5 wich uses AudioSessionInitialize like this AudioSessionInitialize(NULL, NULL, NULL, self); where self here is a ViewController. 回答1: You can't do implicit casts to void* anymore, AudioSessionInitialize(NULL, NULL, NULL, objc_unretainedPointer(self)); should do the trick. EDIT: Historical point, the answer above was from