4 ms·
There is no guarantee when a Java finalizer will run, whereas a C++ destructor is guaranteed to run based on the code that you write. That's a big difference wh
by DougBTX 6y ago
There is no guarantee when a Java finalizer will run, whereas a C++ destructor is guaranteed to run based on the code that you write. That's a big difference which has practical implications, using something with non-guaranteed behaviour as an example of why something with guaranteed behaviour is hard to predict seems like a misunderstanding.
- steveklabnik 6y agoI believe the situation is the same in C++, that is, if you have a shared_ptr cycle, the destructor will never be called, no? It is more deterministic in C++, but you can still call exit(). (which is even more straightforward than the refcount cycle)
- jcelerier 6y ago> I believe the situation is the same in C++, in the specific case of shared_ptr, which are a small part of codebases, if they are even used - for instance an immense amount of C++ GUI programs use Qt which doesn't use shared_ptr-like ownership semantics but instead a tree-of-objects model which does not have this issue. In contrast in Java / C# any object that has a reference to another is at risk.
- steveklabnik 6y agoSure. That’s why I said “more deterministic.” But even a rare event disproves the guarantee.
- DougBTX 6y agoSorry, I meant that the behaviour is guaranteed, not that the destructor is guaranteed to be called. So in the Rc cycle example the guarantee is that the destructor won’t be called.
- steveklabnik 6y agoAh, then I misunderstood you, yes. My bad!
- cle 6y agoOf course it has practical implications and is harder to predict, but neither of those are what this conversation is about.