why allocators are not discussed here

John Colvin john.loughran.colvin at gmail.com
Thu Jun 27 15:50:39 PDT 2013


On Tuesday, 25 June 2013 at 22:22:09 UTC, cybervadim wrote:
> I know Andrey mentioned he was going to work on Allocators a 
> year ago. In DConf 2013 he described the problems he needs to 
> solve with Allocators. But I wonder if I am missing the 
> discussion around that - I tried searching this forum, found a 
> few threads that was not actually a brain storm for Allocators 
> design.
>
> Please point me in the right direction
> or
> is there a reason it is not discussed
> or
> should we open the discussion?
>
>
> The easiest approach for Allocators design I can imagine would 
> be to let user specify which Allocator operator new should get 
> the memory from (introducing a new keyword allocator). This 
> gives a total control, but assumes user knows what he is doing.
>
> Example:
>
> CustomAllocator ca;
> allocator(ca) {
>   auto a = new A; // operator new will use 
> ScopeAllocator::malloc()
>   auto b = new B;
>
>   free(a); // that should call ScopeAllocator::free()
>   // if free() is missing for allocated area, it is a user 
> responsibility to make sure custom Allocator can handle that
> }
>
> By default allocator is the druntime using GC, free(a) does 
> nothing for it.
>
>
> if some library defines its allocator (e.g. specialized 
> container), there should be ability to:
> 1. override allocator
> 2. get access to the allocator used
>
> I understand that I spent 5 mins thinking about the way 
> Allocators may look.
> My point is - if somebody is working on it, can you please 
> share your ideas?

Old but perhaps relevant?

http://www.linkedin.com/news?viewArticle=&articleID=-1&gid=86782&type=member&item=253295471&articleURL=http%3A%2F%2Fwww%2Eallendowney%2Ecom%2Fss08%2Fhandouts%2Fberger02reconsidering%2Epdf&urlhash=96TJ&goback=%2Egmr_86782%2Egde_86782_member_253295471

(It's an academic article about memory allocation from 2002)


More information about the Digitalmars-d mailing list