On Tuesday, 14 July 2015 at 07:01:56 UTC, Ola Fosheim Grøstad
wrote:
As I've written elsewhere. Ready-made-library-allocators don't
solve any real world challenges I have.
I can make do with malloc and mmap where needed. I can write my
own specialised allocator in 10-20 minutes, which I almost
never need, and which is much more likely to perform well than
a library solution since it is written for a specific scenario.
Good for you! I am not sure that suggesting people roll their
own as needed will be conducive to encouraging the adoption of D
for web services - or any other use - though.
What makes D "need" library-allocators is that it was designed
for having a GC
That doesn't appear to have been the rationale for the
subsequently-diluted original idea for including custom
allocators in the non-GC STL. I should have thought allocators
belong in the library because they are rather useful and most of
us would rather not have to bother to roll our own.
There's a big advantage in having a coherent compiler-backed
memory model and let the compiler optimize transparently based
on static analysis, profiling and hints. That's basically what
all high level languages should and do aim for.
Ok. I don't see how the compiler can understand my problem
domain better than me, especially at compile time.
