31–40 of 55 posts
Earlier quoted context omitted.
I think the concern was conserving memory ( which was scarce back then) and not iterating through each substring.
I am very sceptical about that. Much safer and cleaner languages like ML and Lisp were contemporary to C, and were equally developed on memory-scarce hardware.
Earlier quoted context omitted.
Pascal strings might be the only string design worse than C strings. C Strings at least let you take a zero copy substring of the tail. Pascal strings require a copy for any substring! Strings should be two machine words - length + pointer (aka what is commonly called a string view). This is no different than any other array view. Strings are not a special case.
> C Strings at least let you take a zero copy substring of the tail This is a special-case optimisation that I'm happy to lose in favour of the massive performance and security benefits otherwise. Isn't length + pointer... Basically a Pascal string? Unless I am mistaken. I think what was unsaid in your second point is that we really need to type-differentiate constant strings, dynamic strings, and string 'views', whi…
The zero-terminated string is by far C's worst design decision. It is single-handedly the cause for most performance, correctness, and security bugs, including many high-profile CVEs. I really do wish Pascal strings had caught on earlier and platform/kernel APIs used it, instead of an unqualified pointer-to-char that then hides an O(n) string traversal (by the platform) to find the null byte. There are then questions…
Pascal strings might be the only string design worse than C strings. C Strings at least let you take a zero copy substring of the tail. Pascal strings require a copy for any substring! Strings should be two machine words - length + pointer (aka what is commonly called a string view). This is no different than any other array view. Strings are not a special case.
Earlier quoted context omitted.
Besides my DA/Algo classes in College, I've never used C seriously. And you know, it's semantics like this that really make me go WTF lol.... From strtok man page... "The first time that strtok() is called, str should be specified; subsequent calls, wishing to obtain further tokens from the same string, should pass a null pointer instead." Really?? a null pointer.. This is valid code: char str[] = "C is fucking weird…
You have to understand the context, and the time period. Memory and CPU cycles were precious. All computers being 24/7 networked wasn't a thing, so security wasn't much of a concern. API design tended to reflect that.
The null pointer in place of the operand here just seemed like a really good quirk to point out
It's usually the case that the more strident someone is in a blog post decrying innovation, the more wrong he is. The current article is no exception. It's possible to define your own string_view workalike that has a c_str() and binds to whatever is stringlike can has a c_str. It's a few hundred lines of code. You don't have to live with the double indirection.
It's usually the case that the more strident someone is in a blog post decrying innovation, the more wrong he is. The current article is no exception. It's possible to define your own string_view workalike that has a c_str() and binds to whatever is stringlike can has a c_str. It's a few hundred lines of code. You don't have to live with the double indirection.
Earlier quoted context omitted.
Pascal strings might be the only string design worse than C strings. C Strings at least let you take a zero copy substring of the tail. Pascal strings require a copy for any substring! Strings should be two machine words - length + pointer (aka what is commonly called a string view). This is no different than any other array view. Strings are not a special case.
> C Strings at least let you take a zero copy substring of the tail This is a special-case optimisation that I'm happy to lose in favour of the massive performance and security benefits otherwise. Isn't length + pointer... Basically a Pascal string? Unless I am mistaken. I think what was unsaid in your second point is that we really need to type-differentiate constant strings, dynamic strings, and string 'views', whi…
The main difference is that if a string's length is by its data, you can't easily construct a pointer to part of that data without copying it into a new string, whereas if instead the length is by the data's address, you can cheaply construct pointers to any substring (by coming up with new length+address pairs) without having to construct entire new strings.
The zero-terminated string is by far C's worst design decision. It is single-handedly the cause for most performance, correctness, and security bugs, including many high-profile CVEs. I really do wish Pascal strings had caught on earlier and platform/kernel APIs used it, instead of an unqualified pointer-to-char that then hides an O(n) string traversal (by the platform) to find the null byte. There are then questions…
The C string and C++'s backwards compatibility supporting it is why I think both C and C++ are irredeemable. Beyond the bounds overflow issue, there's no concept of ownership . Like if you pass a string to a C function, who is responsible for freeing it? You? The function you called? What if freeing it is conditional somehow? How would you know? What if an error prevents that free? C++ strings had no choice but to co…