why allocators are not discussed here

Jason House jason.james.house at gmail.com
Wed Jun 26 06:16:23 PDT 2013


Bloomberg released an STL alternative called BSL which contains 
an alternate allocator model. In a nutshell object supporting 
custom allocators can optionally take an allocator pointer as an 
argument. Containers will save the pointer and use it for all 
their allocations. It seems simple enough and does not embed the 
allocator in the type.

https://github.com/bloomberg/bsl/wiki/BDE-Allocator-model

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?


More information about the Digitalmars-d mailing list