[braindeath]

Umm.. in any implementation you can already "cast" a std::string to a null-terminated string without a buffer (cf std::string::data() and std::string::c_str()) -- C++11 essentially mandates that. c_str must return "a pointer p such that p + i == &operator[](i) for each i in [0,size()]."

The history of those demonstrate some of the bat-shit insanity of the evolution of C++. Originally data didn't have to null-terminated, but then they finally realized that making c_str actually work without this invariant in general was nearly impossible. So since C++11 data and c_str are equivalent.

Edit: by impossible I really mean something usable with sane complexity requirements -- that wouldn't make people just immediately discard std::string for something better. This is the same C++ that brought you auto_ptr, and other garbage. C++11 corrected many things, this included.

[murderfs]

It was possible with copy on write strings (e.g. libstdc++'s strings until C++11), but C++11 added complexity requirements that outlawed COW strings, because they're only really useful in very specific circumstances, at the cost of making the common case slow.

[zelly]

C++11 was really a new language. It even had a whole new ABI. I'm surprised the transition went smoothly and not like Python 2 to 3.

[foota]

Imo this is probably in part because you can mix the two more easily? I imagine you could link again C++ 2003 code compiled with a compiler understanding the new ABI?

[zelly]

Yes you could[1], but you couldn't link C++11 object code with a C++03 compiler.

[1] with a compiler flag use_cxx11_abi=0 or something

[gpderetta]

If the c++11 object code does not expose any c++11 specific features in its abi/api you should be able to.

[ncmncm]

There was no need to plug in the NUL until somebody called c_str(). That possibility was lost in C++11. Now, if somebody plugs something else there (which is done, UB notwithstanding), c_str() produces the wrong answer.

NUL-terminated strings were one of the dumber things C++ inherited from C, and code that depends on NUL termination is not a thing to be proud of.

[braindeath]

How do you "plugin" the NUL. If there's no space for it, then everytime you want a C string, you need to do an allocation. And why would you put something in it's place - as you said if you modify the c_str that was always UB -- so you pretty much lost all guarantees at that point -- that was just dumb.

Basically the NUL-terminator amounts to a 1-byte of wasted space -- which is almost always completely in the noise -- if you're using std::string for tiny strings you're paying at least 24 bytes anyway. There are just very few cases where that one extra byte matters.

I think the overwhelming opinion is that this 1-byte trade-off is better than the overhead of allocation and copying when you want to pass that string around. NUL-terminated strings aren't important in C++ because of C (well, not directly), but because they are essentially the ABI of countless existing libraries and the major operating systems.

> code that depends on NUL termination is not a thing to be proud of.

Whatever. Code that depends on NUL termination is ubiquitous.

[ncmncm]

>How do you "plugin" the NUL. If there's no space for it, then everytime you want a C string, you need to do an allocation.

You have not thought it through. There was always space for a NUL, but nobody needs it to have a NUL in it until somebody calls c_str(). Anyway, that was true until somebody jiggered the Standard, just before 1998, to require a NUL visible to s[s.size()].

>C Code that depends on NUL termination is ubiquitous.

Fixed that for you.

[braindeath]

> Anyway, that was true until somebody jiggered the Standard, just before 1998, to require a NUL visible to s[s.size()].

This is not technically true. You could plugin your hated NUL byte in the implementation of operator [].

> C Code that depends on NUL termination is ubiquitous.

No, that's not what I said. It really doesn't matter what language underlying the API of all the code that expects NUL terminated strings is written in (a lot of it is C++ of course too). Windows, MacOS, and all POSIX-ish systems have a large API that consumes NUL terminated strings. NUL terminated strings are ubiquitous in computing at this point. Sure blame C from 40 years ago and burn a dmr effigy, I don't care, but that battle was long lost.

NUL terminated strings may be terrible, but the C++ accomodation for them is not -- its a well-thought out trade-off. My understanding is that neither go nor Rust make this trade-off. golangs FFI and syscall overhead has always been something of a performance disaster anyway. C++ has always had a greater demand to "play nice" with legacy code and systems then either of those.

The overhead of just having the NUL-byte is almost always a non-factor. If it really is, then use a byte vector.

[ncmncm]

Buggering op[] would be the slowest possible way to get the NUL there. Some of us would have liked for string operations not to be as absolutely slow as can be achieved. Evidently that is a minority preference.

If you think anybody is complaining about the extra space for the NUL, what you are barking up is not even a tree.

[braindeath]

> Buggering op[] would be the slowest possible way to get the NUL there.

> Evidently that is a minority preference.

What evidence? Pointing out a fact isn't an endorsement.

> If you think anybody is complaining about the extra space for the NUL

Then what exactly are you complaining about? Setting the byte to 0? If not, why are you being so obtuse?

> what you are barking up is not even a tree.

In this thread your tone is repeatedly that of a condescending jerk.

[BubRoss]

Are you saying that there should not be an extra 0 byte at the end until the string fills up and c_str() is called? Inconsistent allocations seem like a recipe for difficult to debug performance problems.

[ncmncm]

> Are you saying that there should not be an extra 0 byte at the end until the string fills up and c_str() is called?

No.