On 10/25/13 5:07 AM, Namespace wrote:
On Friday, 25 October 2013 at 11:21:55 UTC, Jakob Ovrum wrote:
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?
Because Array!int looks a lot more ugly than such a nice thing as int[].
And if it is possible to change the allocator for some arrays, why
shouldn't we implement it?
The default allocator would stay the GC allocator. So if you don't want
to swap the allocator of your arrays, don't do it.
Maintaining per-array-object allocators could be quite expensive. Two
other possibilities are keeping one allocators for all array of a given
type and of course keeping a global allocator for all arrays.
Andrei
