Chromium stack_container for StackString can't work (at least in VisualC++) #4
Description
Symptoms
I was investigating using the chromium stack_container set specifically the StackString. I made a test program with the following:
#include <chromium/base/stack_container.h>
int main() {
StackString<300> s;
return 0;
}
This should create space on the stack and the string would reserve this space.
I was surprised to find, when i added some breakpoints to allocate in StackAllocator that the stack buffer is never returned to anyone. Ie, the general purpose allocater is always called:
pointer allocate(size_type n, void* hint = 0) {
if (source_ != NULL && !source_->used_stack_buffer_
&& n <= stack_capacity) {
source_->used_stack_buffer_ = true; // source_ is always NULL
return source_->stack_buffer(); // and so this is never returned.
} else {
return std::allocator<T>::allocate(n, hint); // This is always called.
}
}
Problem
After further investigation, i found that this is because when the std::basic_string type is created (as part of the construction of StackString) the VisualC++ implementation stores the allocater into some pair. Then when needing to use it, it copies it into a proxy:
void _Alloc_proxy()
{ // construct proxy
typename _Alty::template rebind<_Container_proxy>::other
_Alproxy(_Getal()); // Copies the allocator!
_Myproxy() = _Unfancy(_Alproxy.allocate(1)); // NOTE this for a later point.
...
The copy constructor of the StackAllocator will set the copies stack pointer to NULL. Hence the StackString could never work.
Furthermore, if the StackString didn't have this problem, it immediately allocates space of 1, meaning after you add anything, it will quickly grow and suffer the same problem anyway.
This means the StackString will almost always use normal memory allocation (unless you have a string with 1 char ...).