Objective-C Arc: Strong VS Retain and Weak VS Assign

Objective-C ARC: strong vs retain and weak vs assign

From the Transitioning to ARC Release Notes (the example in the section on property attributes).

// The following declaration is a synonym for: @property(retain) MyClass *myObject;

@property(strong) MyClass *myObject;

So strong is the same as retain in a property declaration.

For ARC projects I would use strong instead of retain, I would use assign for C primitive properties and weak for weak references to Objective-C objects.

Strong vs Retain in ARC

retain is a leftover from the pre-ARC days where you would increase/decrease an objects retain count depending on whether you wanted it to hang around in memory.

Obviously with ARC you no longer have to worry about this and I suspect that retain may simply have been left in for ease of use for the more veteran objective-c programmers out there.

The keywords that are most prevalent with arc are: (strong, weak, nonatomic, readonly, copy).

Exact difference between strong and weak property in ios.....and if ARC is there then why to use strong instead of retain and weak instead of assign

You should look a little bit more in the internet for that question. It is a very common one you should find an answer easily.

Basically strong property are retained and weak are not. For an object you should use weak instead of assign because when released the weak property will be set to nil (not the assign). Keep assign for basic type (int, float, etc.) In ARC strong is defined as retain.

Most of the time:
- for object property (array, dictionnary, etc.) use strong.
- for delegates use weak.
- for basic type (int, float, etc.) use assign.

You will find more detailed answers all over the internet.

What is difference between retain and strong in objective-c?

Strong and Weak help with retain-release cycles (RRC), a form of memory leak. iOS uses something called Automatic Reference Countin (ARC) to know when an object is in use and should be kept in memory, or is no longer in use and should be deleted to gain back resources. ARC works because the runtime knows for each object, how many objects are referencing it. When that found reaches 0, the object is deleted.

Issues arise when you have two objects that hold references to each other. Because object A holds a reference to object B, and B to A, the reference count for both A and B will never be 0, this A and B will always be in memory. It's also possible that there are no other objects holding references to A or B, so we've just created a memory leak.

Getting back to Strong and Weak, these keywords are used to "denote ownership", if you will. They help you eliminate retain-release cycles by limiting what objects increment the reference count for another object. A strong property is one where you increment the reference count of the object. If object A has a strong reference to B, and no other object is referencing B, B has count 1 (A owns, or needs to exist B). Now, if B wants to have a reference to A, we would want to use a weak reference. Weak references don't increment the reference count of the object. So in this particular case, if A has no other objects referencing it but B, A's count would be 0 given B's weak reference.

Can you see how this is eliminating the RRC? Assuming no external references and not using strong/weak references, A and B would perpetually reside in memory. Using the strong and weak references we outlined above, A would have count 0, so it would be removed from memory. This in turn would deincrement B's reference count from 1 to 0, causing B to be removed from memory.

Nonatomic is used to denote that the object being referenced in not thread safe. This means that the object is not able to deal with multiple requests at the same time. Atomicity is the idea that once you make a request, it either happens or it doesn't. When an operation is atomic, you're guaranteeing that the entity you're applying the operation to will never be in an intermediate state. Regardless of how you look at that entity, it either looks the way it did before you requested the operation, or it looks the way it will once the operation is done. (When thinking about atomicity, think of atoms. The word means indivisible. Atomic operations are those which can't be divided into smaller operations.)

differences between weak and assign property?

weak applies to objects (they have reference counts and all the stuff), but weak references don't increase refcount. But once the object is deallocated (from anywhere in the code), any weak reference to that object is set to nil. This is extremely useful, because if you use only strong and weak references, you can't end up with an invalid pointer (pointer to an already deallocated object).

assign does absolutely nothing with the reference, it is usually used for ints, floats and other non-object types. You can of course assign an object reference to such a variable, but if the object is deallocated, you will still have a pointer to it's memory (which is garbage now, and will hurt you when you use it).

Your concerns about "memory use" are weird - references don't take memory, object do. But you can't deallocate an object if you are going to use it. The simple rule for beginners is: for objects, use strong references whenever you can. When you have a reason not to use strong reference, use weak (usually for delegates and datasources). For primitive types (int, float, CGRect, ...) use assign, because they are not objects.

Objective-C - Should we use strong, weak or assign for Class-type?

According to The Secret Life of Classes

A class object is not an instance, but it is definitely a full-fledged object

You don’t have to do anything to create a class object. One class object for every class your program defines is created for you automatically as the program starts up.

Of course, you can use strong for an object.

When is a class object released? - Simple answer is when program is finished.

There is no reason to care about Retain Count of an object which will be never released while program is running. It means that doesn't matter if you use strong/weak/assign, this object is still not be destroyed until program is finished.

So you can use whatever you want, they will give same result.

Differences between strong and weak in Objective-C

A strong reference (which you will use in most cases) means that you want to "own" the object you are referencing with this property/variable. The compiler will take care that any object that you assign to this property will not be destroyed as long as you point to it with a strong reference. Only once you set the property to nil will the object get destroyed (unless one or more other objects also hold a strong reference to it).

In contrast, with a weak reference you signify that you don't want to have control over the object's lifetime. The object you are referencing weakly only lives on because at least one other object holds a strong reference to it. Once that is no longer the case, the object gets destroyed and your weak property will automatically get set to nil. The most frequent use cases of weak references in iOS are:

1. delegate properties, which are often referenced weakly to avoid retain cycles, and

2. subviews/controls of a view controller's main view because those views are already strongly held by the main view.

atomic vs. nonatomic refers to the thread safety of the getter and setter methods that the compiler synthesizes for the property. atomic (the default) tells the compiler to make the accessor methods thread-safe (by adding a lock before an ivar is accessed) and nonatomic does the opposite. The advantage of nonatomic is slightly higher performance. On iOS, Apple uses nonatomic for almost all their properties so the general advice is for you to do the same.

Unsafe_unretain Vs Weak VS Assign

From here, next time you can search the question up on google.

Assign is identical to weak except that it does not set pointers to deallocated instances to nil, potentially leaving dangling pointers. Assign and unsafe_unretained are identical in usage.

Use unsafe_unretained in iOS 4 or below, or else, use assign. Weak is different than unsafe_unretained and assign.

---

Related Topics