A polymorphic_allocator is intended to let you have an allocator whose behavior is dynamically determined at runtime. The only way to create a polymorphic_allocator is: Default constructed, in which case it uses std::pmr::get_default_resource() return value, which is a memory_resource*. Pass it a memory_resource*. copy from another polymorphic_allocator. So the point of customization for a polymorphic_allocator … Read more
At this point no. Allocators in C++ currently are much easier than they used to be. They provide both pmr (polymorphic) and classic allocator support. More importantly, pmr based allocation has not been in heavy use for years. Any weaknesses may still come to light. Fast pool based allocators, or even fixed buffer ones or … Read more
A quoted text from Foundations of Algorithms in C++11, Volume 1, chap 4, p. 35 : template <typename T> struct allocator { template <typename U> using rebind = allocator<U>; }; sample usage : allocator<int>::rebind<char> x; In The C++ Programming Language, 4th edition, section 34.4.1, p. 998, commenting the ‘classical’ rebind member in default allocator class … Read more
You basically have to implement your allocator type to conform to the Allocator concept. The linked page lists all requirements of that type, but the core functionality is implemented in the allocate member function.
I’ve been using Howard Hinnant’s stack allocator and it works like a charm, but some details of the implementation are a little unclear to me. Glad it’s been working for you. 1. Why are global operators new and delete used? The allocate() and deallocate() member functions use ::operator new and ::operator delete respectively. Similarly, the … Read more
For general programming, yes you should use new and delete. However, if you are writing a library, you should not! I don’t have your textbook, but I imagine it is discussing allocators in the context of writing library code. Users of a library may want control over exactly what gets allocated from where. If all … Read more
If you want a container of strings and want to use the same allocator for the container and its elements (so they are all allocated in the same arena, as TemplateRex describes) then you can do that manually: template<typename T> using Allocator = SomeFancyAllocator<T>; using String = std::basic_string<char, std::char_traits<char>, Allocator<char>>; using Vector = std::vector<String, Allocator<String>>; … Read more
Equality of allocators does not imply that they must have exactly the same internal state, only that they must both be able to deallocate memory that was allocated with either allocator. Cross-type equality of allocators a == b for an allocator a of type X and allocator b of type Y is defined in table … Read more
Yes, and this could be useful in some cases. Suppose you have a program that wishes to access more storage than will fit in virtual memory. By creating an allocator that references memory mapped storage and mapping it as required when indirecting pointer objects, you can access arbitrarily large amounts of memory. This remains conformant … Read more
It’s definitely possible to create a fully C++11/C++14 conforming stack allocator*. But you need to consider some of the ramifications about the implementation and the semantics of stack allocation and how they interact with standard containers. Here’s a fully C++11/C++14 conforming stack allocator (also hosted on my github): #include <functional> #include <memory> template <class T, … Read more