Fixing C Strings With String Views
8 points by eliasebner
8 points by eliasebner
I pretty much implement the same thing in every codebase which needs to handle text properly, but the main issue is usually libc pulling you back towards null terminated strings. Also I really dislike that ".*s" requires the length of the string to be an int, but that might change soon.
Yes I also found myself doing this over and over which is why I decided to do it properly once and just reuse it whenever I need it. I'll admit, the printing part is really annoying (what you mention with the length having to be an int), bit what can you do, it's C. We love C even with all its rough edges, am I right?
The problem here is that the author assumes too much. He assumes he understands the problem — more or less invents one — and sets about solving it. Then, as he approaches the very first hurdle, I/O, he cops out and says, well, you know, it really is NUL-terminated.
Among things more or less obviously missing is encoding. He makes a point about how important u8 is (debatable). Why in 2026 does “string” not countenance Unicode?
Was it tested on a machine other than with 8-bit characters? If not, whatever is the point? Any benefit or problem with the choice would be purely the author’s conjecture. There is a reason C chose char to be machine-dependent.
The feature set of the supplied functions is idiosyncratic. There are dozens of string libraries to compare with. How does it measure against std::string in C++ for example or, for that matter, against string.h in C?
The million-character string — that has no NUL! — is exceedingly rare. The need to find the terminator before acting on the data is virtually nonexistent. To compare for equality, for example, it is not necessary to know either length. Simply compare byte-for-byte until one doesn’t match. Not matching the NUL terminator is just one case.
Sorry to rain on the parade. The question of string-handling could fill a book and probably has. A handful of functions and a pointer-length pair just isn’t very interesting.
Was it tested on a machine other than with 8-bit characters? If not, whatever is the point? Any benefit or problem with the choice would be purely the author’s conjecture. There is a reason C chose char to be machine-dependent.
If you only care about systems you use (and POSIX mandates 8 bit char) whatever is the point of supporting those other "strange" systems? Like SQLite: https://sqlite.org/lts.html
(...) SQLite runs on any platform with an 8-bit byte (...)