Comment by goldenkey | Hacker News Reader

Comment by goldenkey | Hacker News Reader

Parent Full thread

Just seems silly to rant against strings in C when they aren't really strings at all. char* is explicity a pointer to a sequence of chars. If a developer wants more things, like a cached length, invalidated by changes, then a lib should be used. A string lib like bstring[0]. I think we get to this precarious place by even considering that char* somehow brings what we could call 'common string functions' to the forefront in an easy way. And of course, assuming the compiler will optimize away code like strlen where it cannot possibly deduce constant memory conditions for the null byte, very silly indeed.

[0] http://bstring.sourceforge.net/

C is low level, but the same mistake could be said for any other language where a function is repeatedly called in a loop. The compiler can only do so much, garbage code is still garbage code. Cache your function calls less they const restricted, and extremely simple, and even then, the compiler might still fail to optimize.

Where do you get the idea that the author is ranting against strings in C? I don't see it.

He's ranting against repeated function calls. Same could be said for any other language. The only interesting thing here is that strlen is the main way to get the length of a string in C, unlike OOP languages that will have a .length accessor that usually keeps the last validated length for o(1) access. That doesn't mean C is subterranean leveled.. it just means the language isn't OOP .. use a lib/struct/functions and the problem is solved. I see this as a baseless attack on C's lack of OOP through some clever bashing.

Storing length with pointer to array has nothing to do with OOP, strings can be defined as simple records (aka structs, product types) you don't need OOP for that:

    struct string_t { const char * buffer; int lenght };

And really, I fail to see any attack on C in this article, it only mentions what a naive programmer might do, and why he/she shouldn't.

That still would not solve the issue as you'd manually be updating length when you modified your string. This is why instead of rolling your own lib, it's probably better to use the existing dynamically allocated C string libs out there to take care of it. Right, all the libs use a struct, as there are no first-class objects in C.

Actually I would prefer to write the length at creation time and don't mutate the string at all (and yes I'm aware that the line of code above is quite far from ensuring immutability); afaik most of those "OOP languages" use immutable strings. But yes, you are absolutely right in most cases using existing libraries is superior solution to any own, rolled-out-just-a-second-ago implementation of string; I used it only to demonstrate that storing length with a buffer address is hardly a OOP technique.

Here's how you'd do that mbel:

   const char[] str = "This is a string";
   int len = sizeof(str) / sizeof(str[0]);

Compile-time..still not dynamic immutability though.

The array pointer can't change, the buffer size can't change, and the char components are const. Immutable but then again, you can violate that quite easily. And it's only compile-time immutability, which isn't all that great.

I'm reading it, and I'm rereading it, and I'm just not seeing that. In fact, I see the author going to great pains to point out that there really are times you want to depend on the non-hoisted conditional behavior of C. This is a heads up, not a "OMG C is teh worst language EVAR!" rant, not even a subtle one.

Read some of the other stuff this guy has written - he's not the type to rant against low level stuff. He is the type to warn beginners about common pitfalls.

Reply on news.ycombinator.com