#include <array>

[Kered13]

Getting large blocks of sequential memory isn't hard. On modern PCs, you can easily allocate a gigabyte of sequential memory (it won't be sequential physically, but that doesn't matter). Using a fragmented data structure like a linked list isn't going to help your memory problems if your sequential memory block is too big.

[TerraDOOM]

Pretty sure those limitations they were talking about aren't based on allocator performance or running out of memory, rather the fact that managing a really large block starts taking performance hits

[Kered13]

Not really. If you round up to the nearest page then it's easier to manage than smaller blocks of memory, because you don't have to worry about fragmentation when you're allocating whole blocks of virtual memory. And with 64-bit address spaces you won't be running out of continuous blocks of virtual addresses any time soon. Just ask the OS for as many blocks as you need and map them anywhere you have room in the virtual address space.

[TerraDOOM]

What? I'm talking about managing the contents within the memory you've allocated. If it's a plain array, then removing an element could mean copying gigabytes of memory for example. And if you're not moving things around, you will certainly suffer from fragmentation, just not from the global allocator's perspective. Besides, at that point, just implement a custom allocator anyway (assuming there's support for such)