I'm a bit confused here.<p>>> Most operators in C++, including its memory allocation and deletion operators, can be overloaded. Indeed this one was.<p>Okay, well, firstly - the issue here seems to be a problem with the implementation of std::allocator, rather than anything to do with overloading global operator new or delete. Specifically, it sounds like the blog author is talking about one of the GNU libstdc++ extension allocators, like "mt_allocator", which uses thread-local power-of-2 memory pools.[1] These extension allocators are basically drop-in extension implementations of plain std::allocator, and should only really effect the allocation behavior for the STL containers that take Allocator template parameters.<p>Essentially, libstdc++ tries to provide some flexibility in terms of setting up an allocation strategy for use with STL containers.[2] Basically, in the actual implementation, std::allocator inherits from allocator_base, (a non-standard GNU base class), which can be configured during compilation of libstdc++ to alias one of the extension allocators (like the "mt_allocator" pool allocator, which does <i>not</i> explicitly release memory to the OS, but rather keeps it in a user-space pool until program exit).<p>However, according to the GNU docs, the <i>default</i> implementation of std::allocator used by libstdc++ is <i>new_allocator</i> [3] - a simple class that the GNU libstdc++ implementation uses to wrap raw calls to global operator new and delete (presumably with no memory pooling.) This allocator is of course often slower than a memory pool, but obviously more predictable in terms of releasing memory back to the OS.<p>Note also that "mt_allocator" will check if the environment variable GLIBCXX_FORCE_NEW (not GLIBCPP_FORCE_NEW as the author mentions) is set, and if it is, bypass the memory pool and directly use raw ::operator new.<p>So, it looks like the blog author somehow was getting mt_allocator (or some other multi-threaded pool allocator) as the implementation used by std::allocator, rather than plain old new_allocator. This could have happened if libstdc++ was compiled with the --enable-libstdcxx-allocator=mt flag.<p>However, apart from explicitly using the mt_allocator as the Allocator parameter with an STL container, or compiling libstdc++ to use it by default, I'm not sure how the blog author is getting a multi-threaded pool allocator implementation of std::allocator by default.<p>[1] <a href="https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/manual/mt_allocator.html" rel="nofollow">https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/ma...</a><p>[2] <a href="https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/manual/memory.html#idm140050801737120" rel="nofollow">https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/ma...</a><p>[3] <a href="https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/manual/memory.html#idm140050801737120" rel="nofollow">https://gcc.gnu.org/onlinedocs/gcc-4.9.4/libstdc++/manual/ma...</a>