automatic-ref-counting

@property definitions with ARC: strong or retain?

陌路散爱 提交于 2019-11-26 07:27:05
问题 Using Xcode 4.2 and ARC, I notice that the auto-generated code for an NSManagedObject still reads like this for properties: @property (nonatomic, retain) NSString * someString; 1) Shouldn\'t retain now be replace with strong or weak ? 2) Why does the auto-generated code still use retain 3) What is the correct replacement for retain in this property statement? I\'m currently debugging a problem using NSFetchRequest , and I thought this might be the source of the problem. Thoughts? 回答1: 1)

What is the difference between Objective-C automatic reference counting and garbage collection?

你。 提交于 2019-11-26 07:17:49
问题 With the new automatic reference counting (ARC) introduced in Xcode 4.2, we no longer need to manually manage retain / release in Objective-C. This seems similar to garbage collection, as done in Objective-C on the Mac, and in other languages. How does ARC differ from garbage collection? 回答1: As I describe in my answer here, ARC can provide the best of both manual memory management and tracing garbage collection. It mostly removes the need for a developer to track manual retains, releases,

AutoLayout: removeFromSuperview / removeConstraints throws exception and crashes hard

ぐ巨炮叔叔 提交于 2019-11-26 06:59:57
问题 We use auto layout constraints selectively, primarily to position labels in relation to editable field elements (UITextView, UITextField, typically). However, since implementing auto layout for these fields, we\'re seeing a nasty exception and crash whenever we\'re unloading views, deallocating, etc. The exceptions are happening as it\'s attempting to remove the constraints from a view before unloading it. Our view/controller hierarchy is as such: UITableViewController (plain style, but with

How do I declare an array of weak references in Swift?

空扰寡人 提交于 2019-11-26 06:58:50
问题 I\'d like to store an array of weak references in Swift. The array itself should not be a weak reference - its elements should be. I think Cocoa NSPointerArray offers a non-typesafe version of this. 回答1: Create a generic wrapper as: class Weak<T: AnyObject> { weak var value : T? init (value: T) { self.value = value } } Add instances of this class to your array. class Stuff {} var weakly : [Weak<Stuff>] = [Weak(value: Stuff()), Weak(value: Stuff())] When defining Weak you can use either struct

capturing self strongly in this block is likely to lead to a retain cycle

怎甘沉沦 提交于 2019-11-26 06:11:21
问题 How can I avoid this warning in xcode. Here is the code snippet: [player(AVPlayer object) addPeriodicTimeObserverForInterval:CMTimeMakeWithSeconds(0.1, 100) queue:nil usingBlock:^(CMTime time) { current+=1; if(current==60) { min+=(current/60); current = 0; } [timerDisp(UILabel) setText:[NSString stringWithFormat:@\"%02d:%02d\",min,current]];///warning occurs in this line }]; 回答1: The capture of self here is coming in with your implicit property access of self.timerDisp - you can't refer to

Can I use Objective-C blocks as properties?

有些话、适合烂在心里 提交于 2019-11-26 05:55:32
问题 Is it possible to have blocks as properties using the standard property syntax? Are there any changes for ARC ? 回答1: @property (nonatomic, copy) void (^simpleBlock)(void); @property (nonatomic, copy) BOOL (^blockWithParamter)(NSString *input); If you are going to be repeating the same block in several places use a type def typedef void(^MyCompletionBlock)(BOOL success, NSError *error); @property (nonatomic) MyCompletionBlock completion; 回答2: Here's an example of how you would accomplish such

What kind of leaks does automatic reference counting in Objective-C not prevent or minimize?

依然范特西╮ 提交于 2019-11-26 05:33:36
In the Mac and iOS platforms, memory leaks are often caused by unreleased pointers. Traditionally, it has always been of utmost importance to check your allocs, copies and retains to make sure each has a corresponding release message. The toolchain that comes with Xcode 4.2 introduces automatic reference counting (ARC) with the latest version of the LLVM compiler , that totally does away with this problem by getting the compiler to memory-manage your stuff for you. That's pretty cool, and it does cut lots of unnecessary, mundane development time and prevent a lot of careless memory leaks that

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

China☆狼群 提交于 2019-11-26 04:57:28
问题 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

Should I refer to self.property in the init method with ARC?

十年热恋 提交于 2019-11-26 04:37:01
问题 A quick question. if I have a property and an ivar declared with the same name: in the .h file: (Reminder*)reminder; @property(nonatomic,strong)(Reminder*)reminder; in the .m file, should I use the ivar or the property in the init method if I\'m using ARC? - (id)initWithReminder:(Reminder*)reminder_ { self = [super init]; if (self) { reminder = reminder_; } return self; } Or should I use the property to get the benefit of the automatic reference counting like this: - (id)initWithReminder:

ARC and bridged cast

廉价感情. 提交于 2019-11-26 04:28:58
问题 With ARC, I can no longer cast CGColorRef to id . I learned that I need to do a bridged cast. According clang docs: A bridged cast is a C-style cast annotated with one of three keywords: (__bridge T) op casts the operand to the destination type T . If T is a retainable object pointer type, then op must have a non-retainable pointer type. If T is a non-retainable pointer type, then op must have a retainable object pointer type. Otherwise the cast is ill-formed. There is no transfer of