On Tuesday, 16 June 2015 at 20:30:50 UTC, Etienne wrote:
On Tuesday, 16 June 2015 at 20:08:36 UTC, rsw0x wrote:
You're attempting to use GC for a problem that they don't
solve because you don't have other tools to fix it. When all
you have is a hammer, everything looks like a nail.
Well no, I have plenty of tools. I use a memory library that
does a wide range of everything I need
https://github.com/etcimon/memutils .. It's not like I'm
reliant only on it, like it's my hammer and I only see nails..
It's simply easier to manage the lifetime of objects through
the GC because sometimes I have them referred to as delegates
at a lower level. I like having finalizers because those
objects may hold thread-local containers.
A GC is not for managing an object's lifetime. There are no
guarantees from the GC.
Isn't that what we'd want? To use the GC only when it's
important and manual memory management at other times? What
happens when you need the two and your manually allocated
objects are tracked by a GC-allocated object?
The correct answer would be for the GC object to be upgraded to
an RCO because the resource's lifetime is now bound to the GC
object.
I think you're the one who's actually looking at everything
like a nail wrt improving performance in benchmarks.
No, I'm looking at correctness and not piling hack upon hack that
will fall apart at the first sneeze to the GC codebase.
Performance just happens to be a side effect of correctness.
