New adapter: std.allocator.quantizer

[Marco Leise via Digitalmars-d]

Am Thu, 07 May 2015 14:12:40 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:

> Helps an allocator without good reallocation capabilities:
> 
> http://erdani.com/d/phobos-prerelease/std_experimental_allocator_quantizer.html
> 
> Destruction welcome.
> 
> 
> Andrei

I haven't tested it, but it seems useful for the cases you
listed in the documentation. While writing dynamic arrays I
remember I had some thoughts about features you used as well:

* "zeroesAllocations"
  I called it "elementsAreInited" and as the name suggests, it
  tells whether new elements receive their T.init
  automatically.
  Now std.allocator deals mostly with raw memory, so zeroing
  is the only option, but I can see some friction coming up
  when typed allocators are built on those.
  Typed allocators backed by a "zeroesAllocations"
  allocator could overwrite the memory 3 times: zeroing,
  T.init, ctor assignments.
  
  a) Could the parent allocator be informed that it does not
     need to zero initialize because we will blit T.init over
     the memory anyways?

  b) If we get zeroed memory, can the typed allocator know at
     compile-time that T.init is all zeroes and elide the blit?

* "roundingFunction"
  This is like a growth function, right? I often have some
  default lying around, but it is sure good to be able to
  provide your own. My default is: n' = n + (n >> 1) + 4
  One thing that could go wrong is that on 32-bit you pick a
  new size like n'=2*n and you just don't find enough
  contiguous virtual memory.
  
  a) On allocation failure the growth function is ignored and
     the minimal required size used.

  b) The growth function needs to be designed more carefully,
     putting the effort on the user.

-- 
Marco