tree: f27e63b84597b3bc34369907a2faef06c40e5e9a [path history] [tgz]
  1. include/

Trivial C++ Allocator Library

The trivial-allocator library provides a small, header-only C++ template implementation of a trivial memory allocator for C++ code. It can provide variants of the C++ new expression syntax using an explicit allocator object.

These allocators are intended for two classes of use:

  1. startup allocations that stay live for the lifetime of the whole program
  2. grouping short-term allocations that will only ever be deallocated en masse

They are never appropriate for general allocation uses where objects are created and deleted cyclically, since there is no reuse of unused memory.

These trivial “leaky” allocators do no real bookkeeping, so individual C++ object allocations cannot really be deallocated or reused. They simply layer on top of a simpler allocation functions (or callable object) that has some means of allocating conveniently-sized (large) chunks, and then they parcel out memory from those chunks. Underlying memory allocated is either wholly leaked or is all kept live during the lifetime of the allocation function object.

Trivial underlying “chunk” allocators to wrap inside the “leaky” allocator are provided for consuming pre-allocated, fixed-sized buffers. It's expected that users of the library will provide simple chunk allocation functions appropriate for their own context.

delete support

A separate companion “stub-delete” library provides no-op operator delete and operator delete[] functions. Linking this in can be necessary not only when delete or delete[] statements may be compiled into the program (even if unreached), e.g. via std::unique_ptr or other “smart pointer” types, but also when any class with virtual functions is used. (The C++ ABI may require special hidden virtual functions generated by the compiler that use delete. These functions will always be linked in even if they can certainly never be reached at runtime.)

The “panic-delete” library is an equivalent alternative whose operator functions will panic like an assertion failure rather than silently leak the memory. It should be used in programs where dead code paths that can't be avoided at link time are the only code paths (if any) that should ever use delete statements.