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