Menu
If my reading of Mike Ash's "Zeroing Weak References" writeup is correct, weak references are like assign references without ARC. However, if the referenced object is deallocated, instead of getting a "dangling pointer" (meaning a pointer that points to a deallocated object), the pointer gets set to nil.
Is this right, and does this happen with any property marked weak or assign (when ARC is active)?
If this is correct, this would eliminate a lot of SIGABRTs.
719
When a weak reference A is created to an object B, there would be an entry in the hashtable modified or created, whose key would be the pointer to B. "Dirty" - to store a special hash-value with each object, which would be zeroed when the object is destroyed.
A weak reference permits the garbage collector to collect the object while still allowing the application to access the object. A weak reference is valid only during the indeterminate amount of time until the object is collected when no strong references exist.
Pointers that are not retained are often referred to as “weak” in Objective-C documentation that predates the garbage collector. These are references that are allowed to persist beyond the lifetime of the object. Unfortunately, there is no automatic way of telling whether they are still valid.
The key difference between a strong and a weak or unowned reference is that a strong reference prevents the class instance it points to from being deallocated. That is very important to understand and remember. ARC keeps track of the number of strong references to a class instance.
It's mostly right, but assign properties are still treated the same as they ever were, only weak ones are zeroing. Another caveat is that zeroing weak references are only available in Mac OS X ≥ 10.7 and iOS ≥ 5. While the rest of ARC was backported to 10.6 and iOS 4, weak references cannot be used at all on these OS's.
179
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
