On Friday, 25 October 2013 at 10:02:08 UTC, Namespace wrote:
On Friday, 25 October 2013 at 09:51:40 UTC, Maxim Fomin wrote:
On Friday, 25 October 2013 at 09:37:23 UTC, Namespace wrote:
We would have then the possibility to manage our memory by
ourself. One of D's promises is, that the GC can be disabled.
Yes, it can, but then we have many many things which do not
work. For example built-in arrays.
Not only arrays, but classes, throwables, scope exits, new
operator, nested structs, etc.
Thats right.
But I often use temporary arrays, but I still don't like them
because they are always consume so much GC memory. But with
allocators that would end.
Let us hope that Walter has the right intention and that Andrei
design the allocators for this purpose.
Why does it have to be the opaque druntime dynamic array? Why
can't you use the hypothetical (planned, rather)
std.container.Array that supports custom allocators, or a type of
your own design?
Garbage collected memory management is the only memory management
paradigm that supports the infinite lifetime model (GC includes
automatic reference counting). Swapping it out for a different
memory management technique while libraries or parts of the
program still rely on infinite lifetime for parts such as the
slice concatenation operators and closures is disastrous.
The best strategy for avoiding the global GC is to not use the
language features associated with infinite lifetime, which
includes slice concatenation and the `new` operator. For implicit
allocations like closures, we don't have much of a choice, so
here the capability is useful, but for slice operators? Just use
a different type!
Currently the `new` operator has capabilities that function calls
cannot replicate - namely non-static nested class construction
and construction of classes with non-public constructors - but
these issues have to be solved anyway to support allocators in
general.
