Question

When I was looking at the way std::string is implemented in gcc I noticed that sizeof(std::string) is exactly equal to the size of pointer (4 bytes in x32 build, and 8 bytes for x64). As string should hold a pointer to string buffer and its length as a bare minimum, this made me think that std::string object in GCC is actually a pointer to some internal structure that holds this data.

As a consequence when new string is created one dynamic memory allocation should occur (even if the string is empty).

In addition to performance overhead this also cause memory overhead (that happens when we are allocating very small chunk of memory).

So I see only downsides of such design. What am I missing? What are the upsides and what is the reason for such implementation in the first place?

Answer 1

Read the long comment at the top of <bits/basic_string.h>, it explains what the pointer points to and where the string length (and reference count) are stored and why it’s done that way.

However, C++11 doesn’t allow a reference-counted Copy-On-Write std::string so the GCC implementation will have to change, but doing so would break the ABI so is being delayed until an ABI change is inevitable. We don’t want to change the ABI, then have to change it again a few months later, then again. When it changes it should only change once to minimise the hassles for users.