CppCon 2014: Alisdair Meredith "Making Allocators Work, Part II"

CppCon · 3K views · 2014 · 1:08:06

Open on YouTube

C, C++, Rust, Go & systems languagesSoftware performance & optimizationtalk

Why Stack Overflow recommends it

Stack Overflow users link it when answering questions about C++11 allocators, scoped_allocator_adaptor, allocator::rebind and custom memory allocation for containers.

Recommended by 2 people across 2 different months, 2015 to 2016.

What it is

A CppCon 2014 conference talk by Alisdair Meredith, chair of the C++ Standard Committee Library Working Group, on how C++11 reworked the allocator model and how allocator_traits works. It also covers runtime polymorphic allocators from the Library Fundamentals TS, aimed at both library authors and consumers.

What people said

Recommends R2-Dequeue · 2015-07 · Stack Overflow · on “Parsing allocator::rebind calls”

@helloB Glad you asked! I do: CppCon 2014: Stephan Lavavej "STL Features And Implementation Techniques" [LINK] CppCon2014: Alisdair Meredith "Making Allocators Work, Part I" [LINK] CppCon 2014: Alisdair Meredith "Making Allocators Work, Part II" [this video] You can get a recent draft standard of C++14 here [LINK] and start with section 17.6.3.5 Allocator requirements [allocator.requirements].

Recommends mattnewport · 2015-09 · Stack Overflow · on “Can I use stl allocators to make both an entire stl container and it's contents (keys and values) be stored inside a memory block that I created?”

Short answer, yes you can do this with C++11 allocators. Allocators are a somewhat complex topic. A good introduction to C++11 allocators can be found in Alisdair Meredith's CppCon 2014 talks part 1 [LINK] and part 2 [this video] C++11 introduced scoped_allocator_adaptor [LINK] which is an important part of making this work when you have nested STL types (e.g. something like a map<string, vector<string>> . A caveat to this however: there is not a good portable way to determine in advance how big your memory block would need to be to accommodate everything you want to store inside it. To be robust and portable you would need to make a 'best guess' up front and then handle a situation where you end

Cites 5gon12eder · 2016-04 · Stack Overflow · on “C++ replacement for C99 VLAs (goal: preserve performance)”

I think you have already enumerated most options in your question and the comments. Use std::vector . This is the most obvious, most hassle-free but maybe also the slowest solution. Use platform-specific extensions on those platforms that provide them. For example, GCC supports variable-length arrays [LINK] in C++ as an extension. POSIX specifies alloca [LINK] which is widely supported to allocate memory on the stack. Even Microsoft Windows provides _malloca [LINK] , as a quick web search told me. In order to avoid maintenance nightmares, you'll really want to encapsulate these platform dependencies into an abstract interface that automatically and transparently chooses the appropriate mecha