On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:
On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner
wrote:
D just does this transparently for you by default. If you
already know the exact or maximum size, you can allocate
*once* (not 6 times) using `new` and `.reserve` respectively
*before* entering the loop, like that article explains in
depth.
You seem to be missing the fact that i pointed this out. The
fact that the GC might have done up to 6 collection rounds in
that loop is "ludicrous".
You wrote:
I if did my own memory management, the variable cleanup will
have been done in one go, right after the loop. Simply more
efficient.
You wrote about cleaning up *after* the loop, *not* about
allocating *before* the loop. They are semantically related (as
allocating with the GC *might* kick off a collection cycle), but
not the same thing.
In my experience most people's aversion to GCs can be aptly
described by the German proverb "Was der Bauer nicht kennt,
das frisst er nicht" (the meaning of which being that most
people generally like living in comfort zones and rarely - if
ever - dare to leave them of their own free will; that
includes developers, sadly).
Unfortunately i do have plenty of experience with GC kicking in
on the wrong moments ( or not at the right moments, people
forget that one ).
In which language(s)? Because in D it's both easy and simple to
avoid that (Use @nogc or compile with `-vgc` and inspect).
Maybe its my opinion only but a good language will not put
anything in the way of the developer but will point out
mistakes.
Safety properties may be what you're looking for. See @safe,
that's an area of D a lot of work is currently being done on.
The Rust compiler is not a bad example but it can be taken a
step more. Is it so hard for developers when you declare a
variable, to later also clean it up???
var x = 1;
// Do work
x.free;
If you write it like that, yes, because often it's not just one
such make/dispose pair per scope, but multiple, possibly
overlapping ones and people make mistakes. And the more complex a
piece of code gets the harder it becomes to decipher such pairs
and/or decide if the "closing" dispose is missing.
This is one of the reasons why scope guards are good:
var x = 1;
scope (exit) x.free
// Do work
This, as code becomes more complex, allows for much easier
reading (and understanding) of lifetimes.
Easy ... Sure, it becomes a little bit more tricky with
ownership but that is where the compiler can help and simply
state: "Hey, you forgot this variable, it does not seem to be
used beyond this point".
Since the GC is memory safe by definition (sans bugs) you'd only
need this for where you aren't using it. And for the rest I'm not
sure it can be done sanely: How's the compiler to know, e.g.,
which functions from a C API (or C++) you call into allocate or
deallocate memory? Introduce yet another keyword or @property to
signal cross-language memory management? If you ignore
cross-language calls and only remain within D, I suppose it might
be viable to write a semantic pass for it, but from my
perspective, the cross-language calls are the *much* bigger
threat to memory safety.
Just calling the x.free seem to be too much work for developers
these days.
In my experience reading about such occurences, this usually
happens when the lifetime of the object the memory is used for
has become unclear.
Up to now i found very few languages that did this correctly.
I don't share your assessment of what's correct, but yes, we
digress.
