Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>For general programming, yes you should use <code>new</code> and <code>delete</code>.</p> <p>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.</p> <p>Users of a library may want control over exactly what gets allocated from where. If all of the library's allocations went through <code>new</code> and <code>delete</code>, the user would have no way to have that fine-grained level of control.</p> <p>All STL containers take an optional allocator template argument. The container will then use that allocator for its internal memory needs. By default, if you omit the allocator, it will use <a href="http://en.cppreference.com/w/cpp/memory/allocator" rel="noreferrer"><code>std::allocator</code></a> which uses <code>new</code> and <code>delete</code> (specifically, <code>::operator new(size_t)</code> and <code>::operator delete(void*)</code>).</p> <p>This way, the user of that container can control where memory gets allocated from if they desire.</p> <p>Example of implementing a custom allocator for use with STL, and explanation: <a href="http://drdobbs.com/cpp/184406243" rel="noreferrer">Improving Performance with Custom Pool Allocators for STL</a> </p> <p><em>Side Note:</em> The STL approach to allocators is non-optimal in several ways. I recommend reading <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1850.pdf" rel="noreferrer">Towards a Better Allocator Model</a> for a discussion of some of those issues.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload