strong / weak / retain / unsafe_unretained / assign

Question

properties for synthesizing the property : retain / assign

• retain - it is retained, old value is released and it is assigned
• assign - it is only assigned

properties for ownership : IOS5 = strong / weak IOS4 = retain / unsafe_unretained

• strong (iOS4 = retain) - i'am the owner, you cannot dealloc this before aim fine with that = retain

• weak (iOS4 = unsafe_unretained) - the same thing as assign, no retain or release

so unsafe_unretained == assign?

@property (nonatomic, assign) NSArray * tmp;

is equal to ?

@property (nonatomic, unsafe_unretained) NSArray * tmp;

and vice versa ?

if so, which one to prefer when in iOS4, or why there is (unsafe_unretained) if its exactly same as assign?

and a delegate in iOS4 should be unsafe_unretained or assign?

Misjoinder

Answer 1

if so, which one to prefer when in iOS4, or why there is (unsafe_unretained) if its exactly same as assign?

you should use unsafe_unretained. You want to show the reader of your code that you actually wanted to use weak but that this was not possible because weak is not available on the iOS version you want to deploy.

One day you will drop the support for iOS4. And then you could just search for unsafe_unretained and replace all of them with weak. This will be much easier than searching for assign and figuring out if you actually meant assign or weak

The use of unsafe_unretained creates more readable and understandable code where the intentions of the developer are easier to see. Basically the same reason we use YES instead of 1.

Dulcy

so in iOS4 assign == unsafe_unretained, but in iOS5 assign != weak, therefore unsafe_unretained where weak should be? right – Misjoinder

and a delegate should be unsafe_unretained or assign? – Misjoinder

a delegate should have a weak assignment. But since weak is not available on iOS4 you should use unsafe_unretained. I don't see a reason to use assign for anything that is not a primitive type (NSInteger, float, ...). In manual memory management we used assign because there was nothing better. But weak is much better because it sets the variable to nil when the object is deallocated. – Dulcy

There are some instances where unsafe_unretained is desired behavior. Not often, though. Weak references are nilled out before the object's dealloc, so an event in dealloc to a delegate might require an unsafe delegate. – Happiness

@MatthiasBauch A weak as opposed to unsafe_unretained delegate was exactly what I needed! Some leftover legacy code still used unsafe_unretained and resulted in Thread 1: EXC_BAD_ACCESS (code=1, address=0x...) errors when performing delegate methods. The delegate had already been dealloced but not niled out it so it actually passed my nil check and began performing selectors against my will :( – Excruciation

Answer 2

There are a few classes in Cocoa and Cocoa Touch that don’t yet support weak references, which means you can’t declare a weak property or weak local variable to keep track of them. These classes include NSTextView, NSFont and NSColorSpace; for the full list, see Transitioning to ARC Release Notes.

If you need to use a weak reference to one of these classes, you must use an unsafe reference. For a property, this means using the unsafe_unretained attribute:

 @property (unsafe_unretained) NSObject *unsafeProperty;

For variables, you need to use __unsafe_unretained:

NSObject * __unsafe_unretained unsafeReference;

An unsafe reference is similar to a weak reference in that it doesn’t keep its related object alive, but it won’t be set to nil if the destination object is deallocated. This means that you’ll be left with a dangling pointer to the memory originally occupied by the now deallocated object, hence the term “unsafe.” Sending a message to a dangling pointer will result in a crash.

Courtesy:Apple (https://developer.apple.com/library/ios/documentation/cocoa/conceptual/ProgrammingWithObjectiveC/EncapsulatingData/EncapsulatingData.html).

Guile