N3916: Polymorphic Memory Resources, r2 -- Pablo Halpern

Save to:
Instapaper Pocket Readability

Note: This paper was among the papers adopted into the draft Library Fundamentals TS yesterday at the Issaquah WA USA ISO C++ meeting.

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N3916

Date: 2014-02-14

Polymorphic Memory Resources -- r2

by Pablo Halpern

Excerpt:

A significant impediment to effective memory management in C++ has been the inability to use allocators in non-generic contexts. In large software systems, most of the application program consists of non-generic procedural or object-oriented code that is compiled once and linked many times. Allocators in C++, however, have historically relied solely on compile-time polymorphism, and therefore have not been suitable for use in vocabulary types, which are passed through interfaces between separately-compiled modules, because the allocator type necessarily affects the type of the object that uses it. This proposal builds upon the improvements made to allocators in C++11 and describes a set of facilities for runtime polymorphic memory resources that interoperate with the existing compile-time polymorphic allocators. In addition, this proposal improves the interface and allocation semantics of some library classes, such as std::function, that use type erasure for allocators.

...

11 Acknowledgements

I’d like to thank John Lakos for his careful review of my introductory text and for showing me what allocators can really do, if correctly conceived. Also, a big thank you to the members of my former team at Bloomberg for your help in defining the concepts in this paper and reviewing the result, especially Alexander Beels, Henry Mike Verschell, and Alisdair Merideth, who reworked the usage example for me. Thanks to Mark Boyall for promoting the addition of new allocators to the standard and for reviewing an early draft of this paper.

Add a Comment

Comments are closed.

Comments (1)

0 0

Arthur Langereis said on Feb 17, 2014 06:32 AM:

After some experience adding allocator support to my own types, I welcome this change with open arms. If I understand well, this would type-erase the allocator for pre-existing types (such as those in std) that already use templated allocators or allow me to add it to my types without any templating at all, correct?

Many non-stdlib implementations use this model and it is often easier to deal with and clearer in general. Thanks.