Re:A Defer Mechanism for C
by DougBTX on Monday December 14, 2020 @10:45AM
(#25418819)
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.
[ Parent
| on HN ]
Re:A Defer Mechanism for C
by steveklabnik on Monday December 14, 2020 @01:06PM
(#25420896)
I 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)
> 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.
Re:A Defer Mechanism for C
by steveklabnik on Monday December 14, 2020 @06:32PM
(#25424872)
Sure. That’s why I said “more deterministic.” But even a rare event disproves the guarantee.
Sorry, 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.
Re:A Defer Mechanism for C
by steveklabnik on Tuesday December 15, 2020 @06:28PM
(#25436845)
Ah, then I misunderstood you, yes. My bad!