On Tuesday, 25 December 2012 at 19:23:59 UTC, Jonathan M Davis
wrote:
On Tuesday, December 25, 2012 16:33:27 Leandro Lucarella wrote:
On Tuesday, 25 December 2012 at 14:48:48 UTC, Sven Over wrote:
>> Phobos does rely on the GC to some extent. Most algorithms
>> and
>> ranges do not though.
>
> Running (library) code that was written with GC in mind and
> turning GC off doesn't sound ideal.
It isn't if you care about memory leaks. And also bare in mind
that some language constructs also relies on the GC, like some
dynamic arrays operations (concatenation and appending for
example). Right now is pretty hard to write D code that doesn't
really use the GC at all.
There's also often no reason not to have the GC on and use it
for certain stuff
but use ref-counted objects as your main type of
memory-management. Then, you
avoid whatever issues the GC has in most cases but don't have
to worry about
what it takes to be able to not use it at all. For instance,
arrays would
probably be GC-allocated in general, since then you can use
slices and
whatnot, but maybe all of your user-defined objects on the heap
could be
malloced and freed with reference counts (though that sort of
thing should be
much easier once we have custom allocators - it's a bit more of
a pain right
now than it should be).
- Jonathan M Davis
In my experience its quite some work to remove the GC entierly,
but it is possible. Also it makes writing Code also easier ans
more effektive in some places because:
-You don't have to register manually allocated blocks with the gc
-You control the exact order of destruction
-You control the time of destruction
-You control in which thread a object gets destructed
-You will be encouraged to not write code that does do 100
allocations just to format a string (because it will leak)
But obviously it has an impact on productivity. But I'm still
more productive writing manual memory managed code in D then in
C++.
Kind Regards
Benjamin Thaut
