why allocators are not discussed here

cybervadim vadim.goryunov at gmail.com
Wed Jun 26 07:10:49 PDT 2013


On Wednesday, 26 June 2013 at 13:16:25 UTC, Jason House wrote:
> 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

I think the problem with such approach is that you have to 
maniacally add support for custom allocator to every class if you 
want them to be on a custom allocator.
If we simply able to say - all memory allocated in this area {} 
should use my custom allocator, that would simplify the code and 
no need to change std lib.
The next step is to notify allocator when the memory should be 
released. But for the stack based allocator that is not required.
More over, if we introduce access to different GCs (e.g. 
mark-n-sweep, semi-copy, ref counted), we should be able to say 
this {} piece of code is my temporary, so use semi-copy GC, the 
other code is long lived and not much objects created, so use ref 
counted. That is, it is all runtime support and no need changing 
the library code.


More information about the Digitalmars-d mailing list