why allocators are not discussed here

[H. S. Teoh]

On Wed, Jun 26, 2013 at 04:10:49PM +0200, cybervadim wrote:
> 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.

Yeah, that's a major inconvenience with the C++ allocator model. There's
no way to say "switch to allocator A within this block of code"; if
you're given a binary-only library that doesn't support allocators,
you're out of luck. And even if you have the source code, you have to
manually modify every single line of code that performs allocation to
take an additional parameter -- not a very feasible approach.


> 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.

Yeah, I think the best approach would be one that doesn't require
changing a whole mass of code to support. Also, one that doesn't require
language changes would be far more likely to be accepted, as the core D
devs are leery of adding yet more complications to the language.

That's why I proposed that gc_alloc and gc_free be made into
thread-global function pointers, that can be swapped with a custom
allocator's version. This doesn't have to be visible to user code; it
can just be an implementation detail in std.allocator, for example. It
allows us to implement custom allocators across a block of code that
doesn't know (and doesn't need to know) what allocator will be used.


T

-- 
Fact is stranger than fiction.