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 method exists, so you can get a pointer to a null terminated character array
That's why the c_str method exists, so you can get a pointer to a null terminated character array
It is as of C++11. The constness of c_str() threw a wrench into that as soon as C++ got a threading model.
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.
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.
Thanks for the explanation!
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.