If I have an empty string and I do .resize() I expected the size and the capacity to be that size. That is not the case in GCC or Clang or MSVC. Requesting a size of 17 gives you a capacity of 30 or 31. And in the case of calling shrink_to_fit(17) both GCC and Clang shrink the capacity to 17, except MSVC, which does nothing and leaves it at 31.
What I want is a way to resize to a specific size and have that capacity, I don't want double the space when I asked for 17. Is this possible without shrinking to fit? I noticed there's resize_and_overwrite in C++ 23 and it behaves the same. I guess if not I need to write my own string class.
The global allocator has to provide __STDCPP_DEFAULT_NEW_ALIGNMENT__ which is 16 bytes on 64 bit systems, the allocator needs to serve chunks of at least 16 bytes of size. and if you ask for 17 bytes the allocator has to reserve 32 bytes, even if you only ask for 17 bytes.
MSVC uses this knowledge and forces the string capacity to always be a multiple of 16, -1 for null terminator, this gives you 31 bytes when you ask for 17, shrinking only shrinks it down to the lowest multiple of 16. this comes in handy if you later push_back into the string.
libc++, can store 22 bytes in the SSO, so it can serve those 17 bytes from SSO online demo, however if you ask for a larger size it uses the same knowledge as MSVC to keep its capacity a multiple of 8 bytes (-1 for null terminator)
libstdc++ is the odd one, it always grows to at least twice its capacity (similar to push_back), and an empty string capacity is 15, because of SSO, so it grows to at least 30 bytes.
MSVC and libc++ behavior is near optimal.
libstdc++ is only problematic if you resize from 127 to 129 because it will grow to 254, otherwise for any size > 30 it will have the capacity you asked for if it was resized from an empty state, and for sizes <= 30 it doesn't matter because the allocator cannot give you less memory.