|
|
|
|
|
by braindeath
2329 days ago
|
|
> 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. |
|
If you think anybody is complaining about the extra space for the NUL, what you are barking up is not even a tree.