manual memory management

[Era Scarecrow]

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.