automatic-ref-counting

问题 The recommended practice is to use property, including private ones through class extension instead of ivar (except in init and dealloc) in the post ARC environment. Aside from it being a recommended practice, what are the main drawbacks in someone using ivar instead of property? I am trying to convince some folks to make the switch but some have argued ivar works just as well and faster. So I would like to collect good solid arguments rather than giving soft statements such as "it's better,

问题 I am having a problem deleting my OpenGL ES textures are created via Quartz 2D and Core Text as shown below : - (void)drawText:(CGContextRef)contextP startX:(float)x startY:(float) y withText:(NSString *)standString { CGContextTranslateCTM(contextP, 0, (bottom-top)*2); CGContextScaleCTM(contextP, 1.0, -1.0); CGRect frameText = CGRectMake(1, 0, (right-left)*2, (bottom-top)*2); NSMutableAttributedString * attrString = [[NSMutableAttributedString alloc] initWithString:standString]; [attrString

问题 I'm a bit confused about ARC behaviour when setting variable that is an input pointer, and is expected to remain valid outside function scope. considering the following example that uses openDirectory framework. @interface bbb -(bool)doSomethingWithADRecord: -(void)obtainADRecord(NSString*)user -(NSString*)getADrecord:(ODAttributeType)attr fromRecord:(ODRecord*)record; @end @interface bbb { ODRecord *_myRecord; } @end @implementation bbb -(void)doSomethingWithADRecord: { // here we access

问题 I am using ARC with ios sdk 6.0. I am pretty sure I have got some memory leaks which Im having trouble tracking down. After running the static analyser, im getting warnings about the following two methods: + (id<MXURLRequest>) requestWithURL:(NSURL*)url { MXASIURLRequest *request = [[MXASIURLRequest alloc] init]; [request setUrl:url]; return request; // STATIC ANALYSER: Potential leak of an object stored into 'request' } - (id)parseBody:(NSError *)error { NSString *contentType = [[_request

问题 I've made an iPhone app using ARC that accesses every entry in the address book, and then every address for every person. The data is stored in CFArrays, which are toll-free bridged to NSArrays. The code is below. ABAddressBookRef addressBook = ABAddressBookCreate(); CFArrayRef arrayRef = ABAddressBookCopyArrayOfAllPeople(addressBook); NSArray *peopleArray =[(__bridge NSArray *) arrayRef copy]; CFRelease(arrayRef); arrayRef = nil; for(id personId in peopleArray) { ABRecordRef person = (_

问题 OK, here's a weird situation I'm facing : I've got an NSWindowController subclass, a window in myMainWindow.xib and the AppDelegate.m invoking the NSWindowController like this : myWindowController* controller = [[myWindowController alloc] initWithWindowNibName:@"myMainWindow"]; [controller showWindow:self]; Now here's what : When ARC is set to NO , then the app runs fine and the windows shows up ok, too. When I set ARC to YES - immediately after I set it (and for JUST 1 run) - it shows a

问题 Below is a simple PerformSelector that sends a message to obj to perform the looping method. All works well but I get the following yellow warning. PerformSelector may cause a leak because its selector is unknown. #import "MyClass.h" #import <Foundation/Foundation.h> int main(int argc, const char * argv[]) { @autoreleasepool { MyClass *obj = [[MyClass alloc]init]; SEL mySel = @selector(looping); [obj performSelector:mySel]; } return 0; } This warning does not make sense because the

问题 I'm having trouble understanding how @autoreleasepool work. Consider the following example in which I am creating an AVAssetReader for an audiofile. To make the memory impact matter, I repeated this step 1000 times. #import <Foundation/Foundation.h> #import <AVFoundation/AVFoundation.h> void memoryTest() { NSURL *url = [[NSURL alloc] initWithString:@"path-to-mp3-file"]; AVURLAsset *asset = [[AVURLAsset alloc] initWithURL:url options:nil]; AVAssetReader *reader = [[AVAssetReader alloc]

问题 Does an app compiled with arc turned on work with iOS 3.1.x devices? Ideally I would like to make our app work only with iOS 4.x and higher but we have some users still running iOS 3.x. I no longer have access to devices with iOS 3. Has anyone tested? 回答1: I wouldn't count on ARC working back to iOS 3.x until you've at least found official documentation to that effect and perhaps tested it yourself as well. Here's at least one opinion that supports the notion that apps written using ARC may

问题 Im currently learning Objective C, and so far Ive been using Automatic Reference Counting with all my projects. However after speaking to some colleagues, and after looking at some forums online, Ive noticed a trend to turn off Automatic Reference Counting and manage memory manually. Ive been wondering if ARC does a good enough job, or if it occasionally drops the ball. Is manually allocating/deallocating memory more efficient? Do some people turn ARC off because that is what they are used to