On Monday, 7 January 2013 at 15:01:27 UTC, Gor Gyolchanyan wrote:
Hello, folks!
I'm on to a project, which requires manual memory management
using custom allocators, but I can't seem to get dynamic arrays
and associative arrays to work.
The std.conv.emplace only allocates the pointer and the size of
the dynamic array and pointer to the associative array, which
is half the issue.
I can work around the dynamic array by manually allocating the
elements of the array and returning a slice to the result
(although I'd be really glad if I could directly use arrays
with my custom allocators).
I got to Page 3 but I really wanted to comment on some of this;
perhaps a step in the non-GC portion.
A thought coming to mind is to modify the existing D language to
include custom allocator/deallocator. The idea of sorta borrowing
from java will do the job. So 'new' can be a function which's
only purpose is to allocate memory, renew can be resizing
(appending?), and release is to handle deallocation.
struct S {
//similar to java's 'new' (C++ as well?) function.
//'this' referencing the struct's current storage/pointer
location.
new(this, int size = S.sizeof) {
assert(size >= S.sizeof);
this = cast(S) GC.malloc(size);
//ctor's called after new ends
}
//array (multidimentional?) allocation handling.
//new[] or newArray?. Probably no ctor afterwards
new(this, int size, int[] multiDimentional ...);
//handles deallocation (if applicable), with GC it's probably
empty
//coinsides with already used releasing of memory.
void release();
//handles resizing (in place?), probably arrays,
//could be realloc() and referring to the current object
already...?
//void realloc(int newSize);
renew(this, int newSize) {
S old = this.ptr;
this.ptr = GC.realloc(this.ptr, newSize);
if (old !is this.ptr)
{} //reallocated not appended
}
//potentially above new could be used for reallocation as
well... So
//rewritten instead as:
new(this, int size = S.sizeof) {
assert(size >= S.sizeof);
this = cast(S) GC.realloc(this, size);
//ctor's called after new ends
}
}
Just a thrown together gist. It's kinda how I remember with
zlib's setup where you could specify the allocator/deallocator,
and if you didn't it used the default. I know it's got problems
as it is, but that doesn't mean it can't be used for
brainstorming to handle alternate memory management.
