3 ms·

Did we read the same article? I read no rant against `strlen`, but rather against naive programmers incorrectly assuming that it could/should be hoisted out by

Did we read the same article? I read no rant against `strlen`, but rather against naive programmers incorrectly assuming that it could/should be hoisted out by an optimizing compiler. There was not one word about being pained by an extra variable, rather that it's a clunky-but-correct solution. And other languages have nothing to do with it; this is strictly a post about C, not a dynamic language, and not C++.

goldenkey 13y ago
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/ 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.
- icodestuff 13y ago
  Where do you get the idea that the author is ranting against strings in C? I don't see it.
  - goldenkey 13y ago
    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.
    - mbel 13y ago
      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.
      - goldenkey 13y ago
        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.
        mbel 13y ago
        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.
        goldenkey 13y ago
        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.
    - icodestuff 13y ago
      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.
- vidarh 13y ago
  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.

goldenkey 13y ago

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/ 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.

icodestuff 13y ago
Where do you get the idea that the author is ranting against strings in C? I don't see it.
- goldenkey 13y ago
  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.
  - mbel 13y ago
    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.
    - goldenkey 13y ago
      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.
      - mbel 13y ago
        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.
        goldenkey 13y ago
        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.
  - icodestuff 13y ago
    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.
vidarh 13y ago
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.