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.

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.

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.

Ah, then I misunderstood you, yes. My bad!

Of course it has practical implications and is harder to predict, but neither of those are what this conversation is about.

If you write a destructor then you know exactly under what circumstances in C++ code it will be used (this is one of the major features of the language). This specific mechanism is extremely important.

Nobody is claiming that it isn’t well-defined nor unimportant.

> something significant is happening that you as the programmer did not explicitly tell it to do.

when I put some object on automatic storage in C++ I do so because I explicitely want it to go away when its scope is left (either by reaching } or through an exception)