I am working on a plugin for an application, where the memory should be allocated by the Application and keep track of it. Hence, memory handles should be obtained from the host
std::vector
uses the unitialized_*
functions to construct its elements from raw memory (using placement new). It allocates storage using whatever allocator it was created with, and by default, that allocator uses ::operator new(size_t)
and ::operator delete(void *p)
directly (i.e., not a type specific operator new
).
vector
uses std::allocator
by default, and std::allocator
is required to use global operator new (that is, ::operator new(size_t)
) to obtain the memory (20.4.1.1). However, it isn't required to call it exactly once per call to allocator::allocate
.
So yes, if you replace global operator new then vector
will use it, although not necessarily in a way that really allows your implementation to manage memory "efficiently". Any special tricks you want to use could, in principle, be made completely irrelevant by std::allocator
grabbing memory in 10MB chunks and sub-allocating.
If you have a particular implementation in mind, you can look at how its vector
behaves, which is probably good enough if your planned allocation strategy is inherently platform-specific.
The actual std::allocator
has been optimized for a rather large extent of size objects. It isn't the best when it comes to allocating many small objects nor is it the best for many large objects. That being said, it also wasn't written for multi-threaded applications.
May I suggest, before attempting to write your own you check out the Hoard allocator if you're going the multi-threaded route. (Or you can check out the equally appealing Intel TBB page too.)
STL containers use an allocator they are given at construction time, with a default allocator that uses operator new
and operator delete
.
If you find the default is not working for you, you can provide a custom allocator that conforms to the container's requirements. There are some real-world examples cited here.
I would measure performance using the default first, and optimize only if you really need to. The allocator abstraction offers you a relatively clean way to fine-tune here without major redesign. How you use the vector
could have far more performance impact than the underlying allocator (reserve()
in advance, avoid insert and removal in the middle of the range of elements, handle copy construction of elements efficiently - the standard caveats).
From this article, "The concept of allocators was originally introduced to provide an abstraction for different memory models to handle the problem of having different pointer types on certain 16-bit operating systems (such as near, far, and so forth)" ...
"The standard provides an allocator that internally uses the global operators 'new' and 'delete'"
The author also points out the alocator interface isn't that scary. As Neil Buchanan would say, "try it yourself!"