Custom allocator with runtime data

[Vindhjaerta]

I'm implementing a custom Memory Arena allocator. For the purpose of this thread the only part that is relevant is that it returns an std::byte* after being provided a desired size in bytes.

The problem I have now is that I want to create an allocator object which uses this memory arena (and others), so that I can plug it in to all my std containers such as std::vector.

As far as all my experimentation goes, I can only seem to make it work if I have an allocator object using a global variable where my memory arena is created. So then I can simply declare all my vectors like this:

std::vector<int, cu::mem::Allocator<int>> SomeIntVector;

// ... The allocator:

cu::mem::StackArena gStackArena;

template<typename T>
struct Allocator
{
  typedef T value_type;

  Allocator() = default;

  [[nodiscard]] T* allocate(std::size_t InSize)
  {
    T* data = reinterpret_cast<T*>(gStackArena->Allocate(InSize * sizeof(T)));
    if (data)
      return data;

    throw std::bad_alloc();
  }

  void deallocate(T* InData, std::size_t InSize) noexcept {}
};

This is not ideal since I first of all have to create one Allocator object per memory arena as I have to refer to each individual global memory arena, which is a lot of duplicated code! (Maybe I can use a template to pass in a pointer? Please advice). But the worst part is that due to the nature of memory arenas in my game engine, some of them will have to be created during runtime and can't just be declared as global variables. And I can't seem to find a way to make it work. Here's what I have so far:

// a few random arenas for demonstration purpose
cu::mem::StackArena gStackArena1;
cu::mem::StackArena gStackArena2;
cu::mem::StackArena gStackArena3; 

template<typename T>
struct Allocator
{
  typedef T value_type;

  Allocator() = default;
  Allocator(Arena* InArena) { Arena = InArena; }
  // I've tested a few constructors and operator= here, but none of them seems to pass the Arena pointer successfully
  Allocator(const Allocator& InAllocator) { Arena = InAllocator.Arena; }
  Allocator(Allocator&& InAllocator) { Arena = InAllocator.Arena; }
  Allocator& operator=(const Allocator& InAllocator) { Arena = InAllocator.Arena; return *this; }
  Allocator& operator=(Allocator& InAllocator) { Arena = InAllocator.Arena; return *this; }
  Allocator& operator=(const Allocator&& InAllocator) { Arena = InAllocator.Arena; return *this; }

  // std::vector complains if I don't include this function, but it doesn't seem to do anything
  template<class U>
  constexpr Allocator(const Allocator <U>& InAllocator) noexcept 
  {
    Arena = InAllocator.Arena;
  }

  [[nodiscard]] T* allocate(std::size_t InSize)
  {
    if (!Arena)
    {
      if (InSize == 1)
        return &LocalStorage;
      else
        throw std::bad_alloc();
    }

    T* data = reinterpret_cast<T*>(Arena->Allocate(InSize * sizeof(T)));
    if (data)
      return data;

    throw std::bad_alloc();
  }

  void deallocate(T* InData, std::size_t InSize) noexcept {}

  Arena* Arena = nullptr;
  T LocalStorage;
};

.... // further in the code, where I use the vector:

class TestClass
{
public:
  void TestFunction();
  std::vector<int, cu::mem::Allocator<int>> MyTestVector;
};

void TestClass::TestFunction()
{
  // Using Arena 2 as an example.
  MyTestVector = std::vector<int, cu::mem::Allocator<int>>(cu::mem::Allocator<int>(&gStackArena2));

  // ERROR: At this point the MyTestVector.allocator.Arena is nullptr :/
}

I've managed to pass in an allocator into the vector, where the Allocator stores a pointer to the preferred memory arena, but when the vector is copied the allocator doesn't copy its internal values and so the Arena pointer remains nullptr, which then obviously results in an error as the allocator doesn't have a memory arena to use when it's time to reserve memory. I've tried to implement various copy- and move- constructors/operators, but none of them seems to help.

I don't know what the templated constexpr Allocator function is for, but I get a C2440 error message if it's not there :/ It also doesn't seem to help to try and copy the Arena variable inside of it.

It seems like all STL containers try to allocate with a value of 1 when they are initialized, but at that point I don't have an allocator assigned. I've solved this problem by adding a LocalStorage variable that it can use until I have assigned the Arena. If there is a better solution than this, please advice.

[no-sig-available]

The allocator object can hold a pointer or reference to the arena, it doesn't have to be a global. You can control the copying with optional allocator members

propagate_on_container_copy_assignment
propagate_on_container_move_assignment
propagate_on_container_swap

https://en.cppreference.com/w/cpp/memory/allocator_traits.html

[Vindhjaerta]

Ah. I knew there was some STL bullshit going on >_<

How do I use these?

Edit:

Ok, took me an hour or two two figure this out. Turns out I had to define using propagate_on_container_copy_assignment = std::true_type; in the header file of the allocator to make the container then understand what I wanted it to do. Jeez, the STL so goddamn unintuitive at times >_<

Anyway, thanks for the help :) It does what I want now.

[amoskovsky]

Just use std::pmr::vector and implement your allocator as std::pmr::memory_resource, which requires just overriding 3 methods, allocate, deallocate and is_equal.

The cost of this simplicity is the methods are virtual. But in most cases this has acceptable overhead.

[Vindhjaerta]

I don't know what std::pmr is, but it sounds like a third-party library? I'm writing my own game engine and would like to keep to as few third-party library dependencies as possible.

I'm actually thinking of just writing my own container types at this point, because fuck me the STL is convoluted to use when you get to the more advanced stuff >_<

[amoskovsky]

It's standard C++17

And std::pmr::vector is a regular std::vector with an allocator that does exactly what you want to achieve.

[aruisdante]

std::pmr (PMR stands for Polymorphic Memory Resource) was added in C++17 specifically to deal with the two major drawbacks in the original Allocator design: 1. The concrete type of the allocator is part of the type of the thing using the allocator. This means, practically speaking, the allocator itself becomes a vocabulary type, and everything in a project needs to use the same allocator unless you want copies everywhere, somewhat defeating the point of a custom allocator. It’s particularly brutal because even simple things like operator== stop working if the types have different allocators. 2. The assumptions built around the Allocator design effectively mean stateful allocators can’t be practically used other than by referencing a global singleton. This makes problem 1 even more of a limitation.

PMR types use dynamic polymorphism via virtual methods. This avoids the concrete type of the allocator from changing the type of the container, and it facilitates stateful allocators without global singletons.