On Saturday, 28 April 2012 at 09:22:35 UTC, Jonathan M Davis
wrote:
On Saturday, April 28, 2012 11:12:21 SomeDude wrote:
Real time guarantees on a GC is not something we are going to
offer anytime soon anyway. While a minimal library, loosely
based
on the C standard library, with some more bells and whistles
that
could be borrowed from Phobos, this is a goal that is
achievable
in a foreseeable future. And both game developers and embedded
programmers would be interested.
If what you want is the C standard library, then use the C
standard library.
There's nothing stopping you, and trying to replicate it in D
would be
pointless.
The main problems with the GC in Phobos are likely arrays and
containers. You
can't fix the array problem. If you do _anything_ which
involves slicing or any
array functions which could allocate, you're going to need the
GC. The only
way to avoid the problem completely is to restrict the
functions that you use
with arrays to those which won't append to an array or
otherwise allocate
memory for an array. The container problem should be resolved
via custom
allocators once they've been added. The custom allocators will
also help
reduce GC issues for classes in general.
But in general, by minimizing how much you do which would
require the GC, the
little that does shouldn't be a big deal. Still, due to how
arrays work,
there's really no way to get away from the GC completely
without restricting
what you do with them, which in some cases means not using
Phobos. I don't
think that there's really any way around that.
- Jonathan M Davis
Right, I understand the situation better now. So basically,
what's needed is the custom allocators, and the GC would be
relieved from much of the work. That would still not work for
hard real time embedded, but for those applications, there are
lots of restrictions on memory anyway (no dynamic allocation for
once), so it wouldn't change much.
