title: Should new C++ code use memory resources instead of allocators?
body: <p>C++17 will bring us <a href="http://en.cppreference.com/w/cpp/memory/memory_resource"><code>std::pmr::memory_resource</code></a> which is a clean interface for allocating and deallocating memory. Unlike the <a href="http://en.cppreference.com/w/cpp/concept/Allocator"><em>Allocator</em></a> concept, it does <em>just</em> that and nothing more. There will also be <a href="http://en.cppreference.com/w/cpp/memory/polymorphic_allocator"><code>std::pmr::polymorphic_allocator</code></a> which wraps a memory resource into a classical allocator so it can be used with existing containers.</p>
  
  <p>If I'm about to write a new container (or other memory-hungry) type targeting C++17 and later, should I continue programming against the <em>Allocator</em> concept or rather use the newer and cleaner abstraction directly?</p>
  
  <p>As of now, my thoughts go like this.</p>
  
  <p><strong>Reasons to continue using allocators:</strong></p>
  
  <ul>
  <li>It is consistent with the standard library and existing code. Even the new <code>std::pmr::*</code> container aliases continue to use allocators.</li>
  <li>Since a memory resource can be wrapped into a <code>std::pmr::polymorphic_allocator</code>, the allocator interface is more general and satisfies the needs of more clients.</li>
  <li>Memory resources always use run-time polymorphism so they have a minor additional run-time overhead compared to the zero-overhead abstraction that allocators can provide.</li>
  <li>Maybe somebody actually needs the other parts of the allocator interface (such as custom pointer types) which cannot be provided by a pure memory resource.</li>
  </ul>
  
  <p><strong>Reasons to start using memory resources instead of allocators:</strong></p>
  
  <ul>
  <li>The allocator interface is clunky and hard to implement. The <code>std::pmr::memory_resource</code> interface is clean and straight-forward.</li>
  <li>Since memory resources are polymorphic, they don't affect the type of the container which means fewer template instantiations (and therefore maybe faster compiles and smaller executables) and enables us to move more code into separate translation units.</li>
  <li>If an object uses a memory resource, it can always instantiate a sub-object that still uses allocators by wrapping the memory resource into a <code>std::pmr::polymorphic_allocator</code>. The other way round is more difficult.</li>
  <li>Memory allocation is a relatively work-intensive task anyway. A single virtual function call doesn't add much overhead, relatively speaking.</li>
  </ul>
  
  <p>Do there already exist any recommendations for how to use the new library feature effectively?</p>