Memory allocators and metaprogramming

When making dynamic allocations, there are two main types- static and dynamic. By that, what I mean is that if you do something like

using Standard;
using Containers;
using Memory;
String.Pointer() sptr = Allocate(String);

In this case, you are actually dynamically allocating a fixed size- sizeof(String). This is begging to be metaprogrammed into an object pool allocation. In fact, the Allocate function knows every type or statically sized allocation you ever passed to it. This means that common allocation sizes can be statically moved to an object pool that fits them. More than that, this re-direction can occur at compile-time, not run-time, alleviating a run-time cost for it.

And, of course, a realloc-style function will be part of the "DeadMG++" Standard allocator interface. After all, the worst you can do is just "return allocate()" if you can't or don't want to implement it.

Another trick that I will employ is the extensive use of custom allocators. The C++ Standard does not really ship any custom allocators, to my knowledge. In "DeadMG++", I will ship with custom allocators. The most obvious to use would be an object pool. In addition, I'm considering a thread-local allocator, and one of my first blog posts was about various memory pool or arena schemes which I could also ship. In addition to the GC, of course. The PPL also provides a special memory allocator. The user's life with a custom allocator is also easier because we provide a slicker interface to them, thanks to named parameters.