4 ms·

This spends a lot of time talking about the C++ Small String Optimization (SSO) but then it decides it doesn't really care about the zero terminator. It is not

This spends a lot of time talking about the C++ Small String Optimization (SSO) but then it decides it doesn't really care about the zero terminator. It is not at all clear to me that the SSO is worth it if you don't need this terminator. C++ has no real choice, it is wedded to C-style zero terminated strings and so the SSO is necessary to be competitive, but if you're rejecting that surely it's time to entirely re-evaluate this data structure ?

SkiFire13 2y ago
Why do you think the SSO is linked to the zero terminator? I always thought it was due to the cost of allocations (and deallocations!) combined with the fact that most strings are actually pretty small.
- tialaramex 2y ago
  Sure, but in a language without the zero terminator the empty string doesn't need an allocation. With a zero terminator, only SSO allows us to avoid that. There are a lot of empty strings. [On a typical modern 64-bit computer] An empty Rust std::String is 24 bytes, exactly the same as the Clang libc++ std::string as somewhat smaller than an MSVC or GCC std::string Most strings are "pretty small" but that's relative. SSO often gives you 15 characters, so the string "http://news.ycombinator.com/ http://news.ycombinator.com/" is far too big, so is my full name, my work email address, a credit card number, and so on. The biggest pay off seems to be that empty string, in Rust's model it's free, in C++ it could not be free without SSO.
  - gpderetta 2y ago
    You can have allocation-less empty std::string even without SSO. The empty string simply uses a statically allocated shared buffer. That's what libstdc++ did in its old refcounted variant, for example. And no, you don't need refcounting.
jstimpfle 2y ago
In any case, heap allocated string buffers like std::string are extremely inefficient as a default data type for short runs of text. Most text for example doesn't need dynamic resizing once it's constructed, so here you can easily save 8 bytes for the "capacity" field. More bytes can be saved by acknowledging that in some situations, zero-terminated for short text runs may not actually be that bad, at least you can save the "size" field. That's another 4 to 8 bytes, probably 8 bytes due to alignment on 64-bit machines. So no need to worry so much about 15 or 16 bytes SSO, or the empty string case (which as the other commenter points out you can easily model with a statically allocated "").

SkiFire13 2y ago

Why do you think the SSO is linked to the zero terminator? I always thought it was due to the cost of allocations (and deallocations!) combined with the fact that most strings are actually pretty small.

tialaramex 2y ago
Sure, but in a language without the zero terminator the empty string doesn't need an allocation. With a zero terminator, only SSO allows us to avoid that. There are a lot of empty strings. [On a typical modern 64-bit computer] An empty Rust std::String is 24 bytes, exactly the same as the Clang libc++ std::string as somewhat smaller than an MSVC or GCC std::string Most strings are "pretty small" but that's relative. SSO often gives you 15 characters, so the string "http://news.ycombinator.com/ http://news.ycombinator.com/" is far too big, so is my full name, my work email address, a credit card number, and so on. The biggest pay off seems to be that empty string, in Rust's model it's free, in C++ it could not be free without SSO.
- gpderetta 2y ago
  You can have allocation-less empty std::string even without SSO. The empty string simply uses a statically allocated shared buffer. That's what libstdc++ did in its old refcounted variant, for example. And no, you don't need refcounting.

jstimpfle 2y ago

In any case, heap allocated string buffers like std::string are extremely inefficient as a default data type for short runs of text. Most text for example doesn't need dynamic resizing once it's constructed, so here you can easily save 8 bytes for the "capacity" field. More bytes can be saved by acknowledging that in some situations, zero-terminated for short text runs may not actually be that bad, at least you can save the "size" field. That's another 4 to 8 bytes, probably 8 bytes due to alignment on 64-bit machines. So no need to worry so much about 15 or 16 bytes SSO, or the empty string case (which as the other commenter points out you can easily model with a statically allocated "").