Class __weak *variable = preExistingObjectWithStrongReference;
If the above code is called, and a object with a strong reference is then pointed to by a new pointer 'variable', and the __weak attribute is assigned to it...
Does that simply mean that the reference count remains untouched? Or does it mean that the original object is now no longer strong referenced?
__weak specifies a reference that does not keep the referenced object alive. A weak reference is set to nil when there are no strong
references to the object.
This means that you can use variable safely as long as there's any other strong reference to the same object. In a certain sense you can think of it as the 'reference count remains untouched' as you said.
Neither; this means that the compiler will keep the reference alive as long as someone else points to it strongly. If there are no more strong references, and all of the objects that refer to your weak pointer are gone, the object is deallocated. Generally you only use weak on objects that you do not own. If you do own them (i.e it is something that "belongs" the the class) then strong is a better choice. A weak is essentially an unretained property, except the when the object is deallocated the weak pointer is automatically set to nil.
Related
As far as I know, when I dereference a dead weak reference in Objective-C, I get a nil value as the result. I'm wondering if there is any way to actually tell if there was a weak value assigned to the variable once it goes away as opposed to simply having a value of nil (for instance if the reference was never assigned).
Is there perhaps a lower-level runtime function that I can use?
I've taken to using a BOOL to record when the reference is assigned, but this feels ugly to me.
As Rob said, you can't do it directly. But you can do so indirectly.
By using associated objects, you can associate a subclass of NSObject with the object being weakly referenced. In that subclass, override dealloc to notify something that the weakly referenced object is being deallocated.
As long as you make absolutely sure that the weakly referenced object's associated reference to your NSObject subclass is the only strong reference to your subclass's instance, then you've effectively created a means of receiving a notification of when the weakly referenced object is deallocated.
Yes, it is fragile. One additional strong reference to that subclass's instances and the whole thing stops working.
No, there is no way to tell if a weak reference has been set to nil because its referent has been deallocated.
The weak reference is set to nil by weak_clear_no_lock in objc-weak.mm.
I am starting with Objective-C development and trying to understand the weak and strong references. I think I understand it, but I am not sure about it...
Let consider that code:
#interface SomeClass {}
#property (nonatomic, weak) NSString* propertyName;
#end
Now, if I invoke somewhere in the code something like this:
NSString* s = someClassInstance.propertyName;
The reference counter is not incremented. Is my understanding correct?
Doubt 1: What is the reference counter value for propertyName?
Doubt 2: So... Could you give an example of when I can get the strong reference to this property? I hope you know what I mean or what I do not understand...
I will get the weak reference.
Declaring propertyName as a "weak" property means two things:
When you assign an object to propertyName, that object's reference count is not incremented.
When the object that propertyName points to is deallocated, propertyName will be set to nil.
Assigning the value of propertyName to another variable may or may not have any impact on the reference count. If you assign it to a strong property, you will almost certainly increase the refcount (since that is part of the semantics of a strong property). But ultimately the compiler will decide if modifying the reference count is necessary.
It's important to understand the concept of object ownership in Objective-C, whether you are using ARC or not, but the details of the actual reference count for a given object at any given moment are not so useful. Remember this: a strong property owns an object. A weak property does not.
First of all
"strong" is synonym of "retain" and "weak" is synonym for "assign" in ARC enabled application.
answer to Doubt 1:
Its retain count will be equal to the retain count of the object it is storing. as it is just a reference.
answer to Doubt 2
Answer to your doubts:
You should refer this link for understanding strong and weak type property
http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1
I am using ARC. I have a method that runs at the end of a game I have written which should clear up memory. There are a series of objects in an NSMutableArray, which i remove using removeObject:. I then set these objects to nil. However, using NSLog on these objects shows that they still exist. Why does setting them to nil not remove them from memory?
In ARC (automatic reference counting), setting a reference to an object to nil means two different things depending on the kind of reference you are nil-ing:
If it is a strong reference, then nil-ing it means decreasing the reference count of the referenced object;
if it is a weak reference, nil-ing it does nothing.
Thus, nil-ing can lead to different outcomes. Specifically, it is only when the reference count goes to zero that the object is deallocated. This would correspond to a case where no other object in the system is owning the first one (which means holding a strong reference to it).
So, in your case there could be either some other objects keeping a strong reference to the objects you try to nil; or, you might be nil-ing a weak reference. If you show some code, it may become clearer.
In ARC, when an object is released, the pointer is set to nil.
How does the object tell all those points that it's about to be released?
Does this work for strong pointers or all types of pointers?
Based on some quick reading of what ARC required be added to the Objective-C runtime, the weak reference itself is registered with the runtime. There are a bunch of calls for setting up a weak connection, tearing it down and reassigning it. The compiler acts to decide what sort of assignment to do, much as it also has a role in automatically retaining and releasing. Per the linked document:
The runtime tracks __weak objects which holds non-null values. It is
undefined behavior to direct modify a __weak object which is being
tracked by the runtime except through an objc_storeWeak,
objc_destroyWeak, or objc_moveWeak call.
From that I'd conclude that the runtime maintains a collection of every weak pointer that currently points to a given object. When that object is deallocated it zeros out the pointers.
So there is a list, per object, that points to the relevant pointers to create a two-directional connection. How and where that's stored isn't explicit — it could be via the existing object association mechanisms, it could be a global dictionary, it could be just about anything.
In ARC (or MRC), a pointer is NOT set to nil when an object is released. In ARC, a weak object reference is set to nil when an object is deallocated, not when it is released. There is a big difference here.
Can someone explain to me in detail when I must use each attribute: nonatomic, copy, strong, weak, and so on, for a declared property, and explain what each does? Some sort of example would be great also. I am using ARC.
Nonatomic
Nonatomic will not generate threadsafe routines thru #synthesize accessors. atomic will generate threadsafe accessors so atomic variables are threadsafe (can be accessed from multiple threads without botching of data)
Copy
copy is required when the object is mutable. Use this if you need the value of the object as it is at this moment, and you don't want that value to reflect any changes made by other owners of the object. You will need to release the object when you are finished with it because you are retaining the copy.
Assign
Assign is somewhat the opposite to copy. When calling the getter of an assign property, it returns a reference to the actual data. Typically you use this attribute when you have a property of primitive type (float, int, BOOL...)
Retain
retain is required when the attribute is a pointer to a reference counted object that was allocated on the heap. Allocation should look something like:
NSObject* obj = [[NSObject alloc] init]; // ref counted var
The setter generated by #synthesize will add a reference count to the object when it is copied so the underlying object is not autodestroyed if the original copy goes out of scope.
You will need to release the object when you are finished with it. #propertys using retain will increase the reference count and occupy memory in the autorelease pool.
Strong
strong is a replacement for the retain attribute, as part of Objective-C Automated Reference Counting (ARC). In non-ARC code it's just a synonym for retain.
This is a good website to learn about strong and weak for iOS 5.
http://www.raywenderlich.com/5677/beginning-arc-in-ios-5-part-1
Weak
weak is similar to strong except that it won't increase the reference count by 1. It does not become an owner of that object but just holds a reference to it. If the object's reference count drops to 0, even though you may still be pointing to it here, it will be deallocated from memory.
The above link contain both Good information regarding Weak and Strong.
nonatomic property means #synthesized methods are not going to be generated threadsafe -- but this is much faster than the atomic property since extra checks are eliminated.
strong is used with ARC and it basically helps you , by not having to worry about the retain count of an object. ARC automatically releases it for you when you are done with it.Using the keyword strong means that you own the object.
weak ownership means that you don't own it and it just keeps track of the object till the object it was assigned to stays , as soon as the second object is released it loses is value. For eg. obj.a=objectB; is used and a has weak property , than its value will only be valid till objectB remains in memory.
copy property is very well explained here
strong,weak,retain,copy,assign are mutually exclusive so you can't use them on one single object... read the "Declared Properties " section
hoping this helps you out a bit...
This link has the break down
http://clang.llvm.org/docs/AutomaticReferenceCounting.html#ownership.spelling.property
assign implies __unsafe_unretained ownership.
copy implies __strong ownership, as well as the usual behavior of copy
semantics on the setter.
retain implies __strong ownership.
strong implies __strong ownership.
unsafe_unretained implies __unsafe_unretained ownership.
weak implies __weak ownership.
Great answers!
One thing that I would like to clarify deeper is nonatomic/atomic.
The user should understand that this property - "atomicity" spreads only on the attribute's reference and not on it's contents.
I.e. atomic will guarantee the user atomicity for reading/setting the pointer and only the pointer to the attribute.
For example:
#interface MyClass: NSObject
#property (atomic, strong) NSDictionary *dict;
...
In this case it is guaranteed that the pointer to the dict will be read/set in the atomic manner by different threads.
BUT the dict itself (the dictionary dict pointing to) is still thread unsafe, i.e. all read/add operations to the dictionary are still thread unsafe.
If you need thread safe collection you either have bad architecture (more often) OR real requirement (more rare).
If it is "real requirement" - you should either find good&tested thread safe collection component OR be prepared for trials and tribulations writing your own one.
It latter case look at "lock-free", "wait-free" paradigms. Looks like rocket-science at a first glance, but could help you achieving fantastic performance in comparison to "usual locking".