Getting Allocators out of Our Way: Exploring Implicit Allocator Awareness in C++
0:26 Performance Benefits: Using custom allocators can significantly improve performance, sometimes achieving up to a 5x speed-up, particularly in scenarios with repetitive string processing by strategically allocating memory (e.g., on the stack).
2:18 Costs of Allocators: While allocators offer performance gains, the primary costs are associated with the infrastructure needed to support them, including the development of allocator-aware classes, potential for misuse, and incompatibility with certain language features.
3:08 Language Proposal: This presentation introduces a language proposal aiming to minimize the costs of using allocators by making custom allocator support transparent in most cases.
5:18 Evolution of Allocators: The proposal builds upon the progress made in C++11 (scoped allocator model, stateful allocators), C++17 (polymorphic allocators, standard memory resources), and C++20 (polymorphic allocator byte).
18:03 Polymorphic Memory Resource (PMR): PMR enables runtime determination of the resource type, allowing for interoperability between modules compiled without knowledge of each other's memory resources.
21:47 Polymorphic Allocator Byte: In C++20, polymorphic allocator byte becomes the recommended default allocator type, simplifying usage and avoiding template bloat.
22:59 Standard Memory Resources: C++17 offers several standard memory resources including new_delete_resource (default heap), unsynchronized_pool_resource (efficient for single-threaded containers), monotonic_buffer_resource (fast allocation, no-op deallocation), and test_resource (debugging and testing).
28:44 Chained Resources: Memory resources can be chained, allowing for fallback mechanisms when a resource is exhausted (e.g., falling back to the heap from a stack-based buffer).
37:26 Allocator-Aware Types: The core of the proposal is the concept of "allocator-aware types," which implicitly accept an allocator argument during construction and propagate it to their members and bases.
42:23 Identifying Allocator-Aware Types: A class is considered allocator-aware if it has any allocator-aware base classes or members, similar to how a class with virtual functions becomes polymorphic.
49:33 Allocator-Aware Aggregates: The proposal extends allocator awareness to aggregates (types without constructors) and standard arrays, enabling their use with custom allocators despite the lack of constructors.
52:53 Backwards Compatibility: The proposal aims for full backwards compatibility. Existing code will continue to work as is, and new allocator-aware types will have a distinct ABI.
56:12 Beyond Allocators: While the initial focus is on allocators, the concepts presented could potentially be extended to other resource management areas, such as executors.
57:16 Conclusion: The proposal aims to simplify the use of allocators, improve code reliability, and promote wider adoption of custom memory management techniques by automating much of the boilerplate code and integration complexities associated with allocators in C++.