automatic-ref-counting | 易学教程

ios: using the same sqlite parameter more than once causes premature memory deallocation

阅读更多关于 ios: using the same sqlite parameter more than once causes premature memory deallocation

问题 Note: the question is misleading.. i thought it was using more than one parameter that causes a memory error.. but that's not the reason.. the reason was an incorrectly formed sql statement.. see the answer below. if create an sqlite statement that uses the same parameter more than once ie NSString* updateStmt = @"INSERT INTO search_email(..., subject, ...)" " SELECT ..., :subject, ...," " coalesce((SELECT search_email.threadID " " FROM search_email " " WHERE search_email.subject MATCH

Why is 'no known method for selector x' a hard error under ARC?

阅读更多关于 Why is 'no known method for selector x' a hard error under ARC?

问题 Maybe it's useful if calling a method that MyClass doesn't understand on a something typed MyClass is an error rather than a warning since it's probably either a mistake or going to cause mistakes in the future... However, why is this error specific to ARC? ARC decides what it needs to retain/release/autorelease based on the cocoa memory management conventions, which would suggest that knowing the selector's name is enough. So it makes sense that there are problems with passing a SEL variable

Weak NSString variable is not nil after setting the only strong reference to nil

阅读更多关于 Weak NSString variable is not nil after setting the only strong reference to nil

I have a problem with this code : __strong NSString *yourString = @"Your String"; __weak NSString *myString = yourString; yourString = nil; __unsafe_unretained NSString *theirString = myString; NSLog(@"%p %@", yourString, yourString); NSLog(@"%p %@", myString, myString); NSLog(@"%p %@", theirString, theirString); I'm expecting all pointers to be nil at this time, but they are not and I don't understand why. The first (strong) pointer is nil but the other two are not. Why is that? David Rönnqvist tl; dr: The problem is that the string literal never gets released so your weak pointer still

Why does ARC retain method arguments?

阅读更多关于 Why does ARC retain method arguments?

问题 When compiling with ARC, method arguments often appear to be retained at the beginning of the method and released at the end. This retain/release pair seems superfluous, and contradicts the idea that ARC "produces the code you would have written anyway". Nobody in those dark, pre-ARC days performed an extra retain/release on all method arguments just to be on the safe side, did they? Consider: @interface Test : NSObject @end @implementation Test - (void)testARC:(NSString *)s { [s length]; //

Why does Apple recommend to use dispatch_once for implementing the singleton pattern under ARC?

阅读更多关于 Why does Apple recommend to use dispatch_once for implementing the singleton pattern under ARC?

What's the exact reason for using dispatch_once in the shared instance accessor of a singleton under ARC? + (MyClass *)sharedInstance { // Static local predicate must be initialized to 0 static MyClass *sharedInstance = nil; static dispatch_once_t onceToken = 0; dispatch_once(&onceToken, ^{ sharedInstance = [[MyClass alloc] init]; // Do any other initialisation stuff here }); return sharedInstance; } Isn't it a bad idea to instantiate the singleton asynchronously in the background? I mean what happens if I request that shared instance and rely on it immediately, but dispatch_once takes until

fake va_list in ARC

阅读更多关于 fake va_list in ARC

问题 I need to create in an iOS application a fake va_list to pass to a NSString initWithFormat:arguments: function, this is my code: NSArray *fixedArguments = [[NSArray alloc] initWithArray:arguments]; NSRange range = NSMakeRange(0, [fixedArguments count]); va_list fakeArgList = (va_list)malloc(sizeof(NSString *) * [fixedArguments count]); __unsafe_unretained id *ptr = (__unsafe_unretained id *)fakeArgList; [fixedArguments getObjects:ptr range:range]; content = [[NSString alloc] initWithFormat

SFHFKeychainUtils. iOS keychain. ARC compatible

阅读更多关于 SFHFKeychainUtils. iOS keychain. ARC compatible

问题 I was wondering if anyone that was using the SFHFKeychainUtils managed to modify them to be compatible for ARC. More exactly the NSDictionary *attributeResult = NULL; NSMutableDictionary *attributeQuery = [query mutableCopy]; [attributeQuery setObject: (id) kCFBooleanTrue forKey:(__bridge id) kSecReturnAttributes]; OSStatus status = SecItemCopyMatching((CFDictionaryRef) attributeQuery,(CFTypeRef *)(attributeResult)); I tried OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)

ARC, Blocks and Retain Cycles

阅读更多关于 ARC, Blocks and Retain Cycles

问题 Working on an iOS project that targets 4.0 and 5.0, using ARC. Running into an issue related to blocks, ARC and referencing an object from outside the block. Here's some code: __block AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:request]; [operation setCompletionBlock:^ { if ([operation isCancelled]) { return; } ... do stuff ... operation = nil; }]; In this case, the compiler gives a warning that using 'operation' in the block is going to lead to a

Why can't I release an object anymore? [duplicate]

阅读更多关于 Why can't I release an object anymore? [duplicate]

问题 This question already has answers here : Under automatic reference counting, why are retain, release, and dealloc not allowed? (4 answers) Closed 6 years ago . After I updated to Xcode 4.2, I can no longer release anything. When I start typing "release" it suggest "release" but with a red line across. If I write it anyway it shows an error and displays these two messages: 'release' is unavailable: not available in automatic reference counting mode Automatic Reference Counting forbids explicit

Some questions about Automatic Reference Counting in iOS5 SDK

阅读更多关于 Some questions about Automatic Reference Counting in iOS5 SDK

I'm currently developing an app for iPad. The development started for iOS 4.2 and is now continuing (and I think will be completed) for iOS 4.3. I just read about ARC in iOS 5, and basically I understood that we will never need to release and retain objects anymore. My questions are: If I decide to upgrade to iOS 5, do I need to remove all [myObject retain] and [myObject release] statements from my code? If I develop a new app for iOS 5 using ARC, will I need to implement some sort of "retro-compatibility" checks? i.e.: will I need to check the version of iOS and call retain and release