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?
