6 ms·

std::string isn't null terminated (or at least it isn't guaranteed to be, I don't think it's forbidden for an implementation to do that). That's why the c_str

• searealist 2y ago
  I think std::string is actually required to be null terminated now in the latest standards. But even before it was basically required as that was the only way to make c_str() constant time.
  • dataflow 2y ago
    > But even before it was basically required as that was the only way to make c_str() constant time. Note that c_str() could've inserted the terminator in constant time, as long as the string kept space reserved for that. So this wouldn't have violated constant-time-ness, and it's not an insane thing to do considering it would save some instructions elsewhere. But yeah, the flexibility wasn't all that useful even in the beginning, and became even more useless as soon as C++ incorporated threading, due to the constness of the function.
• unclad5968 2y ago
  std::string is guaranteed to be null terminated since c++11. std::string::c_str returns the same address as &string[0]
  • dataflow 2y ago
    > std::string::c_str returns the same address as &string[0] Note that this by itself doesn't imply null-termination, though as you say strings are indeed null-terminated now. Edit: This is not particularly obvious, but the reason this has nothing to do with allocation or the return value is that the implementation could still leave space for the null terminator, but avoid actually setting it to zero until c_str() is invoked. That would neither affect the returned pointer nor the constant-time guarantee.
    • masspro 2y ago
      Why downvotes? Ignoring C++11 changes for a minute, c_str is absolutely able to cause a reallocation if it needs to, such that after it returns, its return value and the value of data() are the same. Ergo no, the GP statement alone doesn’t imply anything.
      • dpassens 2y ago
        But the return value guarantee is, as far as I can see, a C++11 change, so you can't ignore those. And as of C++11, c_str is noexcept, so it cannot allocate anything.
        • dataflow 2y ago
          Please see my edit.
    • dietr1ch 2y ago
      Shouldn't c_str() be null terminated? Then if it must point to the actual backing store, then that must also be a valid null terminated C string as there's no other way to use them.
      • dataflow 2y ago
        > Shouldn't c_str() be null terminated? Yes, by definition. > Then if it must point to the actual backing store, then that must also be a valid null terminated C string as there's no other way to use them. No, this doesn't follow. The buffer could leave room for the terminator but not actually write the terminator until c_str() is called. That's why the C++11 standard had to explicitly require that the string always be null-terminated regardless of whether c_str() is called.
        • dietr1ch 2y ago
          Wow, I didn't expect `c_str()` to write at all. I knew that C++ was wild before C++57, but before C++ is insane. Thanks for the explanation!
• dataflow 2y ago
  > std::string isn't null terminated It is as of C++11. The constness of c_str() threw a wrench into that as soon as C++ got a threading model.