On Wednesday, 15 January 2014 at 00:24:48 UTC, Frustrated wrote:
On Tuesday, 14 January 2014 at 22:36:12 UTC, Benjamin Thaut
wrote:
Am 14.01.2014 23:10, schrieb Walter Bright:
I already agreed that there are better ways.
Then this was a big misunderstanding.
So, the issue seems to be that everyone is treating the GC as
the Thors hammer and seeing everything as a nails?
The GC does and can not solve all problems. Why force people to
use it when it doesn't work well?
I would think having a multi-layered approach would be best.
Allow the GC to do everything it can but also allow it to be
configured from 0 to 60. For noobs, non-realtime apps, etc the
GC can be set to do it all. One can trade speed for memory(less
memory, more scanning etc...). One can disable to in specific
cases(such as on unions), have separate heaps for GC memory and
non-GC allocated memory, etc.
It seems that a more robust GC with many features(with the
feature of not using it and either manually allocating or using
ARC).
The the only real issue becomes how to keep the GC in sync with
the non-GC allocated memory... and this only happens if one
chooses to use non-GC features(which must be intentional so
hopefully the programming knows what he's doing if he got that
far).
I doubt this will ever be possible to solve efficiently so why
bother? Leave it up to the programmer to deal with it. Make
some resources available to solve these problems but don't try
to dictate what must be done. If the programmer is going to
bypass the GC he already must have good reasons so why put up
roadblocks? Cause *you* think you know better than him what he
needs to do?
For example, suppose we have a non-GC based pointer. Allow the
programmer to mark it as a pointer with certain contextual
parameters so that either the GC ca n "deal with it" better or
at least for debugging purposes help find memory leaks.
I'm way more interested in having a GC that doesn't stop the
world and a compiler that doesn't require the GC for simple
stuff as slices(could it not use a buffer and/or ARC
instead/alternatively?).
Try to do the pull request that goes with that, and we will be
able to discuss the real problems.
