CppCon 2018: Arthur O'Dwyer “An Allocator is a Handle to a Heap”

preview_player
Показать описание


C++17 introduced the std::pmr framework. In this framework, a std::pmr::polymorphic_allocator<T> holds a pointer to a std::pmr::memory_resource. The memory resource is in charge of managing and organizing the heap itself, and the allocator object is just a thin "handle" pointing to the memory resource.

This is not just a convenient implementation strategy for std::pmr! Rather, this elucidates the true meaning of the Allocator concept which has existed, unchanged, since C++98. An Allocator *is* a (value-semantic) handle to an (object-semantic) MemoryResource. Even std::allocator can — and should — be viewed as a handle to a global singleton "heap", and not as a heap itself.

From this core insight we derive many corollaries, such as the need for allocator types to be lightweight and efficiently copyable, the fundamental impossibility of implementing an "in-place" std::vector via stupid allocator tricks, and the philosophical underpinnings of "rebinding."

Time permitting, we'll
- discuss what we can expect from a "moved-from" allocator object
- relate the notion of "handle" to neighboring notions such as "façade" and "adaptor"
- suggest similarities between "allocator/heap" and "executor/execution-context"

Arthur O'Dwyer

Arthur O'Dwyer started his career writing pre-C++11 compilers for Green Hills Software; he currently writes C++14 for Akamai Technologies. Arthur is the author of "Colossal Cave: The Board Game," "Mastering the C++17 STL" (the book), and "The STL From Scratch" (the training course). He is occasionally active on the C++ Standards Committee and has a blog mostly about C++.


*-----*
*-----*
Рекомендации по теме
Комментарии
Автор

My favorite C++ speaker by far. Learned so much from this guy.

21:45 was the big aha moment for me where things started to click

MyPlanetIsPluto
Автор

The distinction he wanted to make is between _value_ types and _reference_ types.

sjswitzer
Автор

It's not clear to me the following point:

If we ever need more control over memory allocation, using the pmr::memory_resource is the most convenient approach?
Or in some cases a custom one is more suitable?

I cannot imagine how can I implement a frame allocator using the pmr::memory_resource right now, because some object might rung their internal destructor, and freeing the whole allocator without knowing the type of allocated object is wrong. Can you point me to some reosource please?

pancio-ciancio
Автор

I love these videos but it would be cool if the volume was turned a bit higher.

mmmars