News for hackers. Stuff that matters.
Re:A Defer Mechanism for C by greatgib on Monday December 14, 2020 @09:17AM (#25417760)
As replied by someone else, by 'random' I did not mean really 'randomly', because the machine is determinist and follow a logic.

But more that there is so much magic and abstractions that it is very hard for a dev to have a clear view of what is going on and what to expect. He has to 'guess' instead of just read the code. For that, I guess that it is similar to the current question of accountability of decisions made with deep learning algorithms.

As an example of my point, I would refer to the 'garbage collection' issues of a language like 'java'. GC will happen at a logically defined point like 'dirty mem > 100m' but from the developer point of view, his logic could suddenly lag unexpectedly in a middle of a simple operation because the GC was triggered by internal magic. It is very hard for a dev to be able to determine the memory usage at different points of the code and so have a certitude of when this operation could happen.

Re:A Defer Mechanism for C by zabzonk on Monday December 14, 2020 @09:57AM (#25418261)
> As an example of my point, I would refer to the 'garbage collection' issues of a language like 'java'

Two languages could hardly be less alike than Java and C++ - the latter is not garbage collected and where destructors are called is completely predictable.

Re:A Defer Mechanism for C by cle on Monday December 14, 2020 @10:19AM (#25418500)
You’re missing the point. The two are alike in that something significant is happening that you as the programmer did not explicitly tell it to do. The specific mechanism really isn’t an important distinction here.
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.
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)

Re:A Defer Mechanism for C by jcelerier on Monday December 14, 2020 @02:01PM (#25421646)
> 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.
Re:A Defer Mechanism for C by DougBTX on Tuesday December 15, 2020 @01:35PM (#25433349)
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!
Re:A Defer Mechanism for C by cle on Monday December 14, 2020 @04:15PM (#25423414)
Of course it has practical implications and is harder to predict, but neither of those are what this conversation is about.
Re:A Defer Mechanism for C by zabzonk on Monday December 14, 2020 @10:36AM (#25418715)
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.
Re:A Defer Mechanism for C by cle on Monday December 14, 2020 @10:46AM (#25418828)
Nobody is claiming that it isn’t well-defined nor unimportant.
Re:A Defer Mechanism for C by jcelerier on Monday December 14, 2020 @11:56AM (#25419787)
> 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)