I have few questions.
1)where assign property will take memory as we dont need to release for reducing reference count?
2)what is the difference between auto zero reference and non-auto zero reference?how does it work? how will take memory?
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.
assign is like weak but there's no zeroing of the pointer when it leaves the heap. So, it's not as safe as weak.
Related
Update
To clarify, the access of the object during its deinitialization is not being done in its deinit method explicitly. The object in question has listers that get added to it (closures) and these closures are all executed within the deinit method. It is within these closures that accesses of the object is being performed with unowned references. And it is the replacement of those unowned references with unowned(unsafe) references that results in EXC_BAD_ACCESS' from no longer occuring.
It is these unowned(unsafe) references that I'm referring to when asking if they're safe to use if always executed during the object in question's deinit.
Original
I wrote a lot of code predicated on being able to clean up unowned references in the deinitializers of their unowned object. Lo and behold, that is not a feature of unowned references. But apparently it is of unowned(unsafe) references, at least that is the way it appears to be working right now — what once caused a crash accessing an unowned reference during its object's deinitialization, now is no longer crashing and is working as expected.
If guaranteed that all unowned references will not be accessed after deinitialization of their object, would it be safe to use it?
For more details, the aforementioned cleaning up entails removing the object from a set where the hashability is based off its contents' object identities. So if it's a plain unowned reference, when the set attempts to access its hash, it will crash if that procedure is being performed while the object is already deinitializing.
The reason the objects aren't removed from the set before they are deinitialized is because this code is a component of library that enables the addition of nodes to a directed acyclic graph. As a feature, I decided that I would not require consumers of the library to have to remove the nodes when they're done with them, they can simply add them to the graph, then when they're done, release their object (the node) as they would anyways, and because the library adds listeners onto the nodes to remove them from the graph in their deinitializers, it was anticipated that it wouldn't be a problem — that the graph would be able to be cleaned up transparently. Obviously it's a little more complicated now that it's apparent that unowned(safe) references can't be accessed while the object they're referencing is deinitializing.
If unowned(unsafe) works in the way it appears to, it would be a solution to this problem.
The only difference between unowned(safe) and unowend(unsafe) is that the save variant is implemented using proxy objects and it will reliably crash your app when you access it illegally.
The unsafe variant on the other hand is just a plain C-Style pointer which will sometimes "just work" (if by coincidence the memory has not been reused anyway) and sometimes will strangely crash or just report unpredicable results.
unowned is the same as unowned(safe)
Nevertheless, during deinit you may access all the propertys of your object, see The Documentation
And also:
I am not sure exactly what you have implemented but it looks like you are trying to duplicate the mechanism with tables Swift uses internally for keeping track of deallocations of weak references.
If guaranteed that all unowned references will not be accessed after
deinitialization of their object, would it be safe to use it?
Yes it would be safe. If you have this guarantee I think it would also be simpler to turn all your variables to implicitly unwrapped weak variables.
So if it's a plain unowned reference, when the set attempts to access
its hash, it will crash if that procedure is being performed while the
object is already deinitializing.
Obviously it's a little more complicated now that it's apparent that
unowned(safe) references can't be accessed while the object they're
referencing is deinitializing.
I do not think this is the reason for the crash, the memory is freed after deinitialization, during deinitialization you still have access to the instance to perform any manual cleanup you need, I would suggest to replace the complicated solution that keeps track of deallocated references, and simply rely on Swift to set to nil objects that are deallocated using weak references. If you do not want to refactor you code to handle optionals when make them explicitly unwrapped.
However if during deinitialization you access the object from an other reference(outside deinit) it will fail, this is to ensure consistency. See here that access an instance that is deinitialized will cause an app to crash.
This is allowed in Swift 5.0:
class Person {
unowned var child: Person?
}
This is supported by this release notes:
unowned and unowned(unsafe) variables now support Optional types.
(47326769)
I understood exactly the difference between weak and unowned in Swift 4.2 and before. However, I am not sure why Apple decided to make the unowned an optional type. Even in the docs (which are docs for Swift 5.0) this implemented 'proposal' (where can I even find that proposal with the motivation to add optional unowned references?) isn't updated, because it says:
An unowned reference is expected to always have a value. As a result,
ARC never sets an unowned reference’s value to nil, which means that
unowned references are defined using non-optional types.
Above isn't true anymore. The only functional difference that Apple states is that an unowned reference is expected to have an equal or longer lifetime than the object holding that reference. Well, I am curious about the technical use of this.
What difference does it make when I use a weak reference vs an optional unowned reference? Or is the only difference that optional unowned should be used when the referencing object has a longer lifetime? I would expect there must be more...
You've misunderstood the release note and the meaning of the change in the language.
why Apple decided to make the unowned an optional type
They didn't. You can, and usually will, still say
unowned let owner : MyViewController
The only change here is that the unowned variable can be an Optional, which was illegal previously. This change takes care of an annoying edge case, that's all.
Above isn't true anymore
Yes, it is. Things are completely unchanged from before:
Weak references must be typed as Optional; they do not retain the object referred to, but they track the object referred to, and revert to nil if that object goes out of existence.
Unowned references do not retain the object referred to and do not track the object referred to, so it's up to you to prevent that object from going out of existence or you may end up with a dangling pointer and a crash.
The only thing that's changed is that there used to be an additional rule that an unowned reference type could not be an Optional. That rule is now gone.
As you rightly point out, if the unowned reference type is an Optional, this must be a var reference, not a let reference (because having this be an Optional would make no sense if you didn't have the power to change it from nil to an actual value and vice versa).
A typical use case is very much like what you yourself provided:
class Node {
unowned var parent: Node?
}
It seems reasonable to say that this Node may or may not have a parent (because it might be at the top of the graph), but that if it does have a parent, that parent should be unowned (a parent should retain its child, but a child should not retain its parent). Previously, the only way to say that was to make this a weak reference, which entails some unnecessary overhead, and is otiose, because we can absolutely guarantee that if a node has a parent, the parent will outlive the child. Now, you can say what you mean, which is generally a good thing.
Weak and Unowned references are used to prevent retain cycles in the situation where two objects each hold a reference to the other. I get the use of weak but I do not get the use of unowned. Here is Apple's example of a situation where one of the two objects should use an unowned reference:
class Customer {
let name: String
var card: CreditCard?
init(name: String) { self.name = name }
}
class CreditCard {
let number: UInt64
unowned let customer: Customer
init(number: UInt64, customer: Customer) {
self.number = number
self.customer = customer
}
}
The idea is that a credit card cannot exist without a customer. Therefore a credit card can dispense with the optional unwrapping that the use of a weak reference would entail, and can instead use an unowned reference. Hmmm ... so why not use a strong reference? If all other references to the customer were to go away (which is not supposed to happen?) then the credit card's use of an owned reference would result in a crash; whereas its use of a strong reference would result in a memory leak. Huh? A choice between two evils? Better to crash because that is more likely to be noticed during development and testing?
Please help with some insight. Thanks.
Better to crash because that is more likely to be noticed during development and testing?
Yes.
Well, not exactly.
The idea is that your app's design should ensure that no CreditCard instance outlives it's respective Customer instance. When you use unowned, you trust yourself to have a design in play that logically guarantees a crash-free execution.
Now, why would anyone ever use unowned over weak? Simple! unowned removes the whole hassle of Optional unwrapping, and if you know that your CreditCard instance will never outlive it's respective Customer instance, then you should use unowned by all means.
unowned is actually much better than weak, in those situations where it is appropriate (i.e. it is certain that the unowned object will not go out of existence), because:
A weak reference must be an Optional, which may need unwrapping, and
A weak reference entails large amounts of overhead in order to track the reference and change it to nil if it is deallocated, whereas an unowned reference entails zero overhead.
It's actually not a problem because as it stands, the unowned reference does not create any sort of strong reference cycle. When the Customer object is deallocated, its CreditCard will be immediately deallocated as well. Your CreditCard will never get a chance to reference that deallocated Customer.
Very interesting question. Here is some difference between Weak and Unowned References according to Apple's documentation.
Weak References
A weak reference is a reference that does not keep a strong hold on the instance it refers to, and so does not stop ARC from disposing of the referenced instance. This behavior prevents the reference from becoming part of a strong reference cycle.
Unowned References
Like a weak reference, an unowned reference does not keep a strong hold on the instance it refers to. Unlike a weak reference, however, an unowned reference is used when the other instance has the same lifetime or a longer lifetime.
Your question's answer :
weak can become nil, whereas unowned is presumed to never become nil, therefore weak will be optional where as unowned does not need to be optional.
In this case Customer may or may not have CreditCard but no CreditCard should exist without Customer.
Okay, I finally get it:
The last reference to Customer (other than Credit Card's) is set to nil.
ARC checks the Customer's reference count:
Credit Card has a strong reference - Customer's reference count will be 1 so ARC will not deallocate it. Result - memory leak.
or, Credit Card has an unowned reference - Customer's reference count will be 0 so ARC will deallocate it. Doing so will cause Credit Card's reference count to go to 0 causing it to be deallocated. Hence, Credit Card will never have an opportunity to dereference its now nil unowned reference. Result - no crash.
So, if we have designed our code such that holder of the reference (CreditCard) is guaranteed to be deallocated when the referenced object (Customer) is deallocated then we have the kind of scenario wherefore unowned references were designed.
Thanks #Bob
Quick search on this topic revelead this link to another SO answer.
Basically weak references can or cannot be nil, where as unowned references assume that it will never be nil.
You can learn more about them in the Apple docs.
I'm guessing the reasoning behind using an unowned in this case is solely because the unowned is presumed to never be nil (without a customer).
Is the following true:
weak = unsafe_unretain = assign
strong = retain
If it is why they are duplicated ? Which one should we choose?
No, it's not true. weak means that the object is not retained, and additionally, the variable/property will automatically be set to nil when the object is deallocated. unsafe_unretained means the object is not retained, but there is no automatic zeroing. strong and retain are equivalent.
assign is typically used for primitives, like int or double, since you're just assigning. unsafe_unretained is used for Objective-C objects that you know are not being retained, and understand why that's unsafe. weak is a new feature introduced in iOS 5 that is like unsafe_unretained, but has different semantics with ARC. Check out Apple's Advanced Memory Management guide for more info.
In practice, you'll almost never use unsafe_unretained if you're targeting iOS 5 or higher.
strong: variable is retained during its scope. retain also works as a synonym for strong.
copy: creates and retains a copy.
weak: use it to point to an object without claiming ownership. Once the object is released, the pointer will be nil'ed.
unsafe_unretained: same as weak but doesn't nil the pointer after release.
assign: primitive values.
If you're targeting iOS 4, you cannot use weak. Use unsafe_unretained instead.
Before ARC, the default on properties was assign, now the default is strong.
weak != unsafe_unretain
weak will automatically convert its pointer to a nil if the object it is pointing to is deallocated.
Going forward you should use strong & weak for objects and assign for primitive types
Wikipedia states "In computer programming, a weak reference is a reference that does not protect the referenced object from collection by a garbage collector". How do those two types of references look like in code? Does a weak reference is a reference made by an autoreleased message?
The following answer is for the case when there is no garbage collection (such as on iOS).
In the case of garbage collection, there is actually a keyword (__weak) to create a weak reference.
A "weak" reference is a reference that you do not retain.
You need to use these weak references to break up cycles. A common case is a child object that needs a reference to its parent object. In this scenario, the parent would retain a reference to the child object, and the child object has a reference to its parent, but does not retain it. This works because the child object only needs to exist as long as the parent object does.
Does a weak reference is a reference made by an autoreleased message?
Not really, that would be a "very weak reference" ;-)
Auto-released stuff goes away when the call stack is unwound (at the end of every event loop for example). If you need anything to be less temporary, you need to retain a reference (or like in the case above be sure that some other part retains it sufficiently).
A weak reference is a reference that isn't strong enough to force an object to remain in memory while a strong reference forces an object to remain in memory.
If you have created weak reference to any variable, you may get nil for that.
UITableViewDelegate, UIScrollViewDelegate, etc are examples of weak references.
Example of Strong reference :
MyClass *obj1 = [[Myclass alloc] init];
Myclass *obj2 = obj1;
Here obj2 has strong reference to obj1 mean if you remove obj2 from memory then obj1 also get removed.