On Tuesday, 27 January 2015 at 22:46:30 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 24 January 2015 at 23:28:35 UTC, Jerry Morrison
wrote:
On Saturday, 24 January 2015 at 15:04:47 UTC, Ola Fosheim
Grøstad wrote:
If the classes are written for RAII then the destructors have
to be called in reverse order of the constructors. IIRC D
does not guarantee this when you use the GC.
So to do it right there is a lot of GC overhead.
Yes, but the usability question is what do programmers expect?
How much do they assume before turning to the docs?
Unfortunately, I think D is now entrenched in Java/C#ish
expectations. Which is no good, since the main advantage D can
have over those languages is to restrict the language semantics
to a level where D has an inherent performance (timeliness)
advantage.
My expectations from a GC in a system level programming
language would be to give max priority to fast collection at
the expense of features (lean and mean).
It's a big stretch to expect LIFO behavior from garbage
collection. It's not a stretch to expect logging to work.
What does logging in a destructor tell you? The destructor
might not execute until the program terminates.
Logging might help with debugging, say, to log accumulated data
before the object disappears. Perhaps it's not a great example,
but since logging doesn't do anything dubious like forging a
strong link to the object, it would seem safe at first
expectation.
Because of this unknown delay before GC collection, also because
GC can collect a cycle of objects, we know it can't promise LIFO
order.
You might not expect LIFO from the GC, but can you trust
library authors to ensure that it does assume LIFO when manual
memory management becomes commonplace?
Sorry, I don't understand the question. I expect LIFO for freeing
structs on the stack.
D needs to define what it means by "safe" and "convenient". It
is currently very much up in there air when it applies and when
it does not.
Yes.
The forum discussion
http://forum.dlang.org/thread/gvaacvczsrybguddo...@forum.dlang.org?page=1
deals with an InvalidMemoryOperationError. Vladimir Panteleev
created a wiki page
http://wiki.dlang.org/InvalidMemoryOperationError on how to debug
such cases, starting with building a patched Druntime. Very
helpful, but not easy.
==> It would be a big step forwards if the runtime printed a
clear error message like: "Attempt to allocate GC memory within
the destructor for class Foo."
