As far as I know, libstdc++'s representation has two advantages: First, it simplifies the implementation of `s.data()`, because you hold a pointer that invaria

As far as I know, libstdc++'s representation has two advantages: First, it simplifies the implementation of `s.data()`, because you hold a pointer that invariably points to the first character of the data. The pointer-less version needs to do a branch there. Compare libstdc++ [1] to libc++ [2]. [1]: https://github.com/gcc-mirror/gcc/blob/065dddc/libstdc++-v3/include/bits/basic_string.h#L225-L228 https://github.com/gcc-mirror/gcc/blob/065dddc/libstdc++-v3/... [2]: https://github.com/llvm/llvm-project/blob/1a96179/libcxx/include/string#L1936-L1938 https://github.com/llvm/llvm-project/blob/1a96179/libcxx/inc... Basically libstdc++ is paying an extra 8 bytes of storage, and losing trivial relocatability, in exchange for one fewer branch every time you access the string's characters. I imagine that the performance impact of that extra branch is tiny, and massively confounded in practice by unrelated factors that are clearly on libc++'s side (e.g. libc++'s SSO buffer is 7 bytes bigger, despite libc++'s string object itself being smaller). But it's there. The second advantage is that libstdc++ already did it that way, and to change it would be an ABI break; so now they're stuck with it. I mean, obviously that's not an "advantage" in the intuitive sense; but it's functionally equivalent to an advantage, in that it's a very strong technical answer to the question "Why doesn't libstdc++ just switch to doing it libc++'s way?"