Deinit Method Is Never Called - Swift Playground

Deinit method is never called - Swift playground

Xcode's Playgrounds for Swift don't work like regular apps; they aren't being run just once. The objects created stay in memory and can be inspected until you change the code, at which point the whole playground is reevaluated. When this happens, all previous results are discarded and while all object will be deallocated, you won't see any output from that.

Your code is correct, but Playgrounds is not suited to test things related to memory management.

Here's a related SO question: Memory leaks in the swift playground / deinit{} not called consistently

deinit not called in specific case

I expect deinit to be called at program termination

You should not expect that. Objects that exist at program termination are generally not deallocated. Memory cleanup is left to the operating system (which frees all of the program's memory). This is a long-existing optimization in Cocoa to speed up program termination.

deinit is intended only to release resources (such as freeing memory that is not under ARC). There is no equivalent of a C++ destructor in ObjC or Swift. (C++ and Objective-C++ objects are destroyed during program termination, since this is required by spec.)

Swift: no output for println in deinit method (not using playground)

While I don't see an explicit reference that says "Swift's deinit has exactly the same semantics as ObjC's dealloc," it is hard to imagine that this isn't true, since Swift and ObjC objects are both managed by ARC and generally speaking interchangeable.

Given that, this is exactly expected. Cocoa does not deallocate objects at program termination. It just terminates, leaks all the memory, file handles, and other system resources, and leaves it to the OS to cleanup. This makes program termination dramatically faster than it would be otherwise.

This is an important point because it means you generally should not use deinit to manage anything other than OS-managed resources (certainly not anything that you require to run). Of course, there's no way to guarantee that a destructor runs, even in C++. If you crash, it won't happen, and your program would have to deal with that. You can think of it as all Cocoa programs quietly crashing when they terminate.

So in your case, a = nil is causing deinit to be run, while program termination does not.

How to call deinit in Swift

The problem is that a playground is not real life. This is just one more reason for not using them (I think they are a terrible mistake on Apple's part). Use a real iOS app project and deinit will be called as expected.

Example from a real project:

class ViewController: UIViewController {
class Person{
let name:String;
init(name:String){
self.name = name;
println("\(name) is being initialized.");
}
deinit{
println("\(name) is being deInitialized.");

}
}
override func viewDidLoad() {
super.viewDidLoad()
var person:Person?;
person = Person(name:"leo");
person = nil;
}
}

That does what you expect it to do.

deinit in empty swift Project not called

No. In this case the ViewController deinit isn't even being called because ViewController doesn't go out of memory.

A way to test this is to create a new ViewController and replace the current ViewController with it. This should remove your current ViewController out of the memory, hence calling it's deinit method.

deinit not called inside uiviewcontroller after pressing back - Swift

Beware that a view controller going out of the screen does not mean that it will be deallocated afterwards. I would recommend moving the timer dealloc to viewDidDisappear, but obviously it depends what you are using that timer for as well.



Related Topics



Leave a reply



Submit