An allocator model for std2
C++17 reserves the namespace std2 (and others) for future iterations of the standard library that may not be 100% compatible in design with the current namespace std. This session will suggest a much simpler allocator model that might be useful for that new library. What is an allocator model, and why should we care? There are a variety of experiments and benchmarks around now demonstrating the benefits that a well-chosen allocator can bring to performance-sensitive code. We would like to bring those benefits to any new standard library, but without the complexity that plagues the specification of allocators in the current standard library. An allocator model is a set of rules for writing and supplying allocators to typed and objects, and the set of rules those types should follow when using a custom allocator. Following the principle that you should not pay for what you do not use, we will look into creating a model with minimal impact on code and complexity on users — in fact we will demonstrate (in theory) a model that will typically involve writing no code for users to support custom allocators in their type, and a runtime cost that can be entirely eliminated in programs that never choose a custom allocator! This presentation is a thought experiment in a possible future direction, and still a year or so away from becoming a proposal for standardization — in particular it will rely on creating a new language feature that we should demonstrate in a practical compiler. It offers a vision of a possible future for the language, and some of the problems that we would like to solve.