automatic-ref-counting

问题 When I do something simialr to the following I get an error saying for (UIView* att in bottomAttachments) { if (i <= [cells count]) { att = [[UIView alloc] extraStuff] } } Fast Enumeration variables cannot be modified in ARC: declare __strong What does __strong do and why must I add it? 回答1: If a variable is declared in the condition of an Objective-C fast enumeration loop, and the variable has no explicit ownership qualifier, then it is qualified with const __strong and objects encountered

问题 When I do something simialr to the following I get an error saying for (UIView* att in bottomAttachments) { if (i <= [cells count]) { att = [[UIView alloc] extraStuff] } } Fast Enumeration variables cannot be modified in ARC: declare __strong What does __strong do and why must I add it? 回答1: If a variable is declared in the condition of an Objective-C fast enumeration loop, and the variable has no explicit ownership qualifier, then it is qualified with const __strong and objects encountered

问题 I have a category class for NSString. @implementation NSString (URLEncode) - (NSString *)URLEncodedString { __autoreleasing NSString *encodedString; NSString *originalString = (NSString *)self; encodedString = (__bridge_transfer NSString * ) CFURLCreateStringByAddingPercentEscapes(NULL, (__bridge CFStringRef)originalString, NULL, (CFStringRef)@"!*'();:@&=+$,/?%#[]", kCFStringEncodingUTF8); return encodedString; } Am I using the correct bridge transfers for ARC and the new LLVM? The original

问题 I have a category class for NSString. @implementation NSString (URLEncode) - (NSString *)URLEncodedString { __autoreleasing NSString *encodedString; NSString *originalString = (NSString *)self; encodedString = (__bridge_transfer NSString * ) CFURLCreateStringByAddingPercentEscapes(NULL, (__bridge CFStringRef)originalString, NULL, (CFStringRef)@"!*'();:@&=+$,/?%#[]", kCFStringEncodingUTF8); return encodedString; } Am I using the correct bridge transfers for ARC and the new LLVM? The original

问题 I have window controller and view controller that use core data bindings, but I want to be able to have those views really, truly get deallocated. I then want to reset the managedObjectContext and at that point have given up as much memory as possible. I have found that I am required to unbind things which I've bound in the Nib, or the MOC keeps the Nib objects retained. The issue is this EXEC_BAD_ACCESS trace: If I do not unbind all of the bindings, even those created in Interface Builder,

问题 I have converted my app to use ARC. Before I had the following line of code: NSArray *colors = [NSArray arrayWithObjects:startColor, endColor, nil]; Since the implicit conversion of a non-Objective-C pointer type to 'id' is disallowed with ARC, I rewrote the line like this: NSArray *colors = [NSArray arrayWithObjects:(__bridge id)startColor, (__bridge id)endColor, nil]; Everything works fine on the simulator, however on the device the app crashes on the mentioned line with the error message:

问题 This is my pattern: 1) SpecialView creates a MessageView and holds a strong reference to it. 2) User taps a button in MessageView which causes it to fade out. MessageView then tells it's delegate, SpecialView, that it faded out completely. 3) SpecialView releases MessageView. The problem is this: - (void)fadedOut:(NSString*)animationID finished:(NSNumber*)finished context:(void*)context { [self.delegate messageViewFadedOut:self]; // delegate releases us... // self maybe got deallocated...

问题 I Have an iOS app with multiple view controllers and ARC enabled. One of the view controllers has an IBOutlet for UIScrollView and UIPageControl . When that view controller is loaded this error is printed in the console: *** -[NSRecursiveLock dealloc]: lock (<NSRecursiveLock: 0xcb88cb0> '(null)') deallocated while still in use While trying to fix the problem, I created a symbolic breakpoint for the symbol _NSLockError with the module set to Foundation. Now Xcode breaks with breakpoint 1.1 on

问题 I'd like to understand if there is any advantage in declaring properties ivars instead of letting the compiler do it for us, considering only to build code for IOS5.. I think that the best practice should be not to declare them, otherwise you should remember of things like declaring ivars as __weak if the corresponding property is declared as weak.. it is necessary to do that, right? Otherwise the weak property is assigned to a strong ivar by default and it is no more weak... 回答1: I usually

问题 I am pushing my UIViewController subclass onto the navigation stack; however, since it is being retained by the navigationController, I 'release' my pointer to it after pushing it onto the stack so that when it is eventually popped the viewController will be dealloc-ed. However, it's not working, the dealloc method for the viewController is never called. The code looks something like this: MyViewController *newViewController = [self.storyboard instantiateViewControllerWithIdentifier:@"foo"];