Exceptions vs destructors

[embryo2]

Because all heap objects have an owner somewhere on the stack (directly or indirectly)

If an object was create in function main and the program exit is also in function main, then the object never will be released (only when program exits). It means it is possible to allocate something, to write a destructor for it, but because of an exception, the point, where the destructor is called, will be missed (may be even a thread will be killed, but program doesn't exit, main's stack is present and all it's referenced objects are alive).

Also, it can be said, that every object has an owner somewhere in the heap. But no automatic memory management system can determine if an object is still in use or not if a developer just forget to set the object's reference to null.

Generally speaking, the detection of a situation, when an object should be released, is not as simple as Rust designers think (only stack based deallocation is not enough).

[Rusky]

Nope. An object owned on main()'s stack will be destructed when main() ends, regardless of whether that's through finishing the program or through unwinding. The only way around that is through an abort, which applies equally to finally blocks.

You can keep making things up, but RAII is an established way of managing memory and it has an answer to anything you can come up with.

[Roman]

Personally, I always thought that automatic memory management is pretty simple. My compiler would insert code that would increment/decrement reference counters on getting/losing references. This is how ARC in Objective-C works.

[Nable]

Personally, I always thought that automatic memory management is pretty simple. My compiler would insert code that would increment/decrement reference counters on getting/losing references. This is how ARC in Objective-C works.

And how are you going to fight with circular references?

[Roman]

Personally, I always thought that automatic memory management is pretty simple. My compiler would insert code that would increment/decrement reference counters on getting/losing references. This is how ARC in Objective-C works.

And how are you going to fight with circular references?

As I understand, Objective-C (and other languages) solves this with "strong" and "weak" references.