CppCon 2017: Pablo Halpern “Allocators: The Good Parts”
Vložit
- čas přidán 3. 06. 2024
- CppCon.org
-
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2017
-
Memory allocators have a bad rap. Sure, they give us control, sometimes vital control, over how and where memory is allocated, but they seem so hard to use correctly. The allocator model that was first standardized in C++98 was put in place to solve a different problem; despite being called "allocators," control over memory allocation was, at best, a secondary consideration. Changes in C++11 and C++17 corrected many of the flaws, at the cost of complexity in the specification. If only there were a user manual and tutorial for allocators, much of that complexity would fall away and could be ignored. This talk strives to be that user manual and tutorial, intended to focus your attention on the important parts of modern allocators, and leaving most of the legacy stuff from 1998 behind. We will look at the easiest way to design a class that uses allocators, and walk through the creation of a real, useful allocator. In the process, I will introduce features in C++17 that can easily be adapted for use with today's C++11 and C++14 standard libraries. My goal is to make allocators approachable, so that you can use them appropriately in your own work.
-
Pablo Halpern: Intel
Pablo Halpern has been programming in C++ since 1989 and has been a member of the C++ Standards Committee since 2007. His work with allocators began at Bloomberg LP, where he developed an appreciation for the simple and powerful allocator model in use there. In 2005, he started writing standards proposals to add the benefits of the Bloomberg Allocator model into the C++ allocator model. After Bloomberg, Pablo worked on C++ extensions for parallelism at Cilk Arts, Inc., and continued that work at Intel Corp after Intel acquired Cilk Arts in 2009. His currently work at Intel is on compiler technology for new processor architectures and he continues to focus on exploiting hardware parallelism through compiler technology, language extensions, and libraries. In the standards committees, he promotes adoption of parallel and vector constructs into the C++ and C standards, as well as continued improvements to the allocators. He lives with his family in southern New Hampshire, USA. When not working on compilers and parallel programming, he enjoys studying the viola, skiing, snowboarding, and watching opera.
-
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*
The clearest explanation of pmr to newbies.
I could be wrong, but the "protected virtual functions" pattern mentioned around 15:53 sounds like a textbook implementation of the Template Method pattern, which is an approach to inversion of control while guaranteeing algorithmic consistency in derived classes. It is often used to prevent the "Call Super" anti-pattern. If you tried re-implementing them without the protected virtual functions, you would probably find that to implement the methods in the subclass, you would frequently need to explicitly call the base class methods.
That was a great talk!
Yes, it was and highly pertinent given that C++17 is truly where custom allocators go from being not far from rubbish to awesomeness.
This is a great talk.
Pablo is hero.
what do I need to read to understand what he's talking about?
Great talk. good part is good.
Great talk.
Thank you, great talk
Glad you enjoyed it!
If std::polymorphic_allocator is the real deal, why are all these pmr container allocators typedefd to the type (e.g. for vector) using vector = std::vector with type T?
11:58 can anyone explain why the copy assignment doesn't copy/move the allocator? Is that specific to std::basic_string? He also mentioned it never should, but I don't get why not either.
He said latter on that prior to pmr, allocator of a same type (remember it's a template parameter...) are all considered equal and that prevented doing stateful allocator. I guess it's the reason : Since the contained CustomStrings all use the same CustomAlloc TYPE (and not instance), their allocators are considered equal no matter of the instance
Clear talk but I feel like there are some bits missing. I wish he had gone through a complete example: resource -> allocator -> container. For instance: In the resource there is an alignment parameter, but in the polymorphic allocator that's gone. How do I make an aligned container? (there is an `aligned_alloc`, but that completely bypasses this resource stuff)
I wonder how you guys did decide on "null_memory_resource" to throw exception instead of just returning null... It is hard to convince rational people to use "virtual" but it is impossible to make them enable exceptions.
The purpose of the null_memory_resource is to basically stop the computation if memory allocation is attempted from that resource. Unlike other allocators, throwing bad_alloc does not signal an out-of-memory condition but rather a program error (memory is being allocated when it shouldn't be). Typically, the program will terminate when the exception is thrown, as most programs cannot recover from bad_alloc. However, throwing bad_alloc is the interface that was agreed to since the very first C++ standard, so null_memory_resource is simply staying with the interface. In fact, no allocator should ever return null, since the Allocator requirements state that either memory is allocated or bad_alloc is thrown.
I’d like to know what you think would happen if you try to work with an object with a null address, and why that would be preferable to a bad alloc exception.
Actually, on embedded system, you can have the whole memory accessible, even the address 0. I agree though that using exception add some overhead that is not always needed. Depends what language you learn first. For performance critical code, I would go with something similar to errno
Where do you learn all that? I am about to lose my nerves. I started learning programming 2 years ago but I didnt go the bootcamp route (js and rails). I decided to write complex programs like parsers and rewriting network protocols from scratch yet I don't understand what you guys are talking about. I might soon completely breakdown and just leave this field as it seems too vast to ever be able to become an expert in it. At least doctors have clear defined specialties but it seems that in programming you have to know it all. For instance the guy talking about throwing an exception instead of returning null that question is too subjective and you'll have different people recommend different things. This is exactly my experience with stackoverflow. As soon as the question is not simple, you'll often have people arguing about approaches that you wonder from where they get them and you will feel so lost at that point. Anyways the last blow I've had to take lately is trying to fix a github open-source issue for one week only to have someone fix it and state "I am not familiar nor with the codebase nor the language". And still he fixed it without even asking a question or requiring additional information. I cried that night and I hated myself so much. Sorry guys but I feel so overwhelmed and during my 4 years at college I've never felt that way even when the courses were tagged as hard. I feel I am competing against the best and that the competition is everywhere I feel that no matter I try to push I am always left behind. Thanks in advance for any advice coming from you guys.
@@somehrjdbddhsjsbnsndndk751 2 years is nothing. Try 20 years and talk again. Computer programming, especially C++, is really hard. And it gets harder if you care about the nifty details like memory, shared access and complex recursive datastructures. I cry every night.
do allocators provide a performance benefit?
See the talks from John Lakos to get an extensive answer: czcams.com/video/nZNd5FjSquk/video.html czcams.com/video/nZNd5FjSquk/video.html . In short: Yes, they do.