3 ms·

C++11 mandatory null termination has the advantage that a call to data() or c_str() need not store the null byte. On the other hand, mandatory termination costs

by romed 8y ago

C++11 mandatory null termination has the advantage that a call to data() or c_str() need not store the null byte. On the other hand, mandatory termination costs one additional store in some of the constructors, and burns one byte of the capacity for inline data.

kazinator 8y ago
How does it burn one byte of capacity for inline data? Are you saying there is a zero-byte way to encode the length that could instead be used, avoiding that one byte overhead?
- romed 8y ago
  What I meant was the standard requires the null byte at the end of the string, which reduces by one the possible length of the string when stored inline. If the null byte wasn't mandatory, it would be possible to store slightly longer strings inline, but then the implementation would have to conditionally materialize the contents to the heap in case of a call to c_str or data.
  - saagarjha 8y ago
    Only since C++11. In C++03 no guarantees were given on the time complexity on c_str, and std::strings could lay their contents our however they wished (and cause a heap allocation in the process of materializing a C string, if necessary).
- dwaite 8y ago
  std::string has a byte length,an allocation capacity, a nil terminator and the content. A string implementation will typically store this as a structure with size + capacity + content pointer, with the content having a nil terminator. You could technically put capacity as a prefix of the content as well (I believe one of the apple GC string representations stores capacity as well as a reference count in the content block, and uses the reference count to determine exclusive ownership for inline mutation.) These may have two other representations: - size, capacity and content all initialized to zero is the only representation of the empty string - a embedded flag (such as a tagged contents pointer) indicates that instead the string holds inlined data. In this inlined case on a 64-bit platform, you have 24 bytes to work with. You store the length in the LSB byte of the content pointer (making sure not to interfere with the tagging), and capacity is hard coded and omitted. You then have 23 bytes to work with, which would be 23 bytes of content - but you need to remember to add space for a nil byte at the end of the inlined content, bringing your capacity down to 22.
  - saagarjha 8y ago
    > std::string has a byte length,an allocation capacity, a nil terminator and the content. This is only true post C++11, I believe. C++03 was much more permissive about how std::strings were laid out internally.

by romed 8y ago

kazinator 8y ago

How does it burn one byte of capacity for inline data? Are you saying there is a zero-byte way to encode the length that could instead be used, avoiding that one byte overhead?

romed 8y ago
What I meant was the standard requires the null byte at the end of the string, which reduces by one the possible length of the string when stored inline. If the null byte wasn't mandatory, it would be possible to store slightly longer strings inline, but then the implementation would have to conditionally materialize the contents to the heap in case of a call to c_str or data.
- saagarjha 8y ago
  Only since C++11. In C++03 no guarantees were given on the time complexity on c_str, and std::strings could lay their contents our however they wished (and cause a heap allocation in the process of materializing a C string, if necessary).
dwaite 8y ago
std::string has a byte length,an allocation capacity, a nil terminator and the content. A string implementation will typically store this as a structure with size + capacity + content pointer, with the content having a nil terminator. You could technically put capacity as a prefix of the content as well (I believe one of the apple GC string representations stores capacity as well as a reference count in the content block, and uses the reference count to determine exclusive ownership for inline mutation.) These may have two other representations: - size, capacity and content all initialized to zero is the only representation of the empty string - a embedded flag (such as a tagged contents pointer) indicates that instead the string holds inlined data. In this inlined case on a 64-bit platform, you have 24 bytes to work with. You store the length in the LSB byte of the content pointer (making sure not to interfere with the tagging), and capacity is hard coded and omitted. You then have 23 bytes to work with, which would be 23 bytes of content - but you need to remember to add space for a nil byte at the end of the inlined content, bringing your capacity down to 22.
- saagarjha 8y ago
  > std::string has a byte length,an allocation capacity, a nil terminator and the content. This is only true post C++11, I believe. C++03 was much more permissive about how std::strings were laid out internally.