CppCon2014: Alisdair Meredith "Making Allocators Work, Part I"
Why Stack Overflow recommends it
Stack Overflow users link it as the go-to introduction to C++11 allocators when answering questions about custom allocators, rebind, and container memory control.
Recommended by 2 people across 2 different months, 2015 to 2019.
What it is
A CppCon 2014 talk by Alisdair Meredith, chair of the C++ Standard Committee Library Working Group, on how the C++11 allocator model works and how it improves on the C++98 design. It also covers polymorphic allocators from the Library Fundamentals TS and uses allocator_traits as a case study in compile-time reflection.
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" [this video] CppCon 2014: Alisdair Meredith "Making Allocators Work, Part II" [LINK] 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 [this video] and part 2 [LINK] 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 sunny · 2015-07 · Stack Overflow · on “Contiguous memory allocation for several small std::vectors?”
@MSalters my understanding is that nowadays the compiler ignores the allocator type for purposes of determining template type (saw that somewhere in this presentation: [this video] )...but even if this were not that case, I'm ok with that...if I can find a solution. What Chris Drew pointed to seems the most likely, except I want to allocate contiguous memory on the heap.
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
Cites Nathan Chappell · 2019-05 · Stack Overflow · on “std::list thread_safety”
I wanted to find out if lists were thread safe in general, so I asked and found this thread. The conclusion I've come to, is that, in the current implementation of std::list in gcc libstdc++, you may safely modify a list in one thread, and arbitrarily iterate through lists concurrently, but don't dare have two threads modifying the same list (without syncronization). Furthermore, this behavior should not be depended upon. I've ripped up the library code to point out the issues in a bit greater detail. I hope that it is helpful. First let's start with the general question of thread safety for lists. I figured it would be nice to "prove" that lists are unsafe by example, so I threw the followi