3 ms·

What I don’t understand is why C programmers use the built in strings. It’s like rolling your own sorting algorithm every time you need it. Surely someone could

What I don’t understand is why C programmers use the built in strings. It’s like rolling your own sorting algorithm every time you need it. Surely someone could write a better string library in C that hides the complexity. The real problem is that C programmers are apparently allergic to using other people’s code.

TimTheTinker 6y ago
... except for libc, which apparently which is hardly ever questioned.
cycloptic 6y ago
There are a large number of those libraries. Every large C project eventually seems to grow its own string class.
user5994461 6y ago
>>> Surely someone could write a better string library in C that hides the complexity. In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries. Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object oriented at all, and that prevents from making things like a nice string library. If you're curious, the closest thing you will see in the C world is something like GTK, a massive C library including string and much more (it's more known as a GUI toolkit but there are many lower level building blocks). It's an absolute nightmare to use because everything is some abuse of void pointers and structs.
- zlynx 6y ago
  I think you mean GLib as seen here https://developer.gnome.org/glib/stable/glib-Strings.html https://developer.gnome.org/glib/stable/glib-Strings.html GLib and GTK are closely aligned parts of GNOME so they are easy to get mixed up.
  - user5994461 6y ago
    Right. The string library is in glib. There were a few big libraries in the ecosystem if I remember well, GTK, glib and another two. They're from the same origin and often mixed together. It's been almost a decade since I dabbled into this stuff day-to-day. I think being forced to use glib is the turning point in a developer's life where you realize you simply have to move on to a more usable language.
    - Tteriffic 6y ago
      So true
- c-cube 6y ago
  Strings have nothing to do with objects. You can write a string library, eg. [sds](https://github.com/antirez/sds https://github.com/antirez/sds). It's just not standard.
  - user5994461 6y ago
    The challenge is not to write a string library, but to write a "nice" string library. Let's say, something that's easier to use and doesn't have all the footguns of the char arrays. The library you link doesn't come anywhere close to that. It's 99% like the standard library and it has the exact same issues.
    - mariusor 6y ago
      I would love to see what you mean by "exact same issues". sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings. If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C ecosystem considers as strings. Keeping an API which is very similar to the standard library is also a plus, as it doesn't force developers to change the way they reason about the code.
      - CRConrad 6y ago
        > sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings. Wait, haven't I seen that idea somewhere else...? > If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C ecosystem considers as strings. Aha, strings as byte arrays but with a built-in length marker. But yeah, Pascal is sooo outmoded and inferior to C... Sigh.
    - kergonath 6y ago
      You’re moving goalposts now. Just earlier you wrote that you couldn’t write a library in C because C does not support objects, not that you couldn’t write a nice library (for whatever definition of “nice” you want to use, which will be different from someone else’s). In fact there are several libraries for string-like objects; the main barrier to use them is that none of them is standard. You can at least acknowledge that before talking about nice-ness, which is a whole other point.
- phlakaton 6y ago
  What rubbish! You do not need objects to make a library. Structs, typedefs, and functions do just fine. There are even techniques in C to define abstract data types if you want! Take another look at https://developer.gnome.org/glib/stable/glib-Strings.html#g-string-new-len https://developer.gnome.org/glib/stable/glib-Strings.html#g-... . That’s all C, baby, and could be replicated in a completely independent strings-only library built on the standard library if you wished. The reasons no such library exists are ecological, not technical.
kelnos 6y ago
Because most projects involve interfacing with other third-party libraries that will undoubtedly not know about this other third-party library that implements a nice string.
- kaba0 6y ago
  It can contain a to_cstring() function and problem solved. If it uses a struct with length of string and pointer to a c-style string, even the conversion can be elided (at the price of some inflexibility/unnecessary copying while in use)
  - kelnos 6y ago
    That would mean you lose the ability to do all sorts of optimizations and memory sharing. Or at least, you can do them, but then the c_string() function requires copying the data. And that also means that it's a one-way thing: you can't use the copy on something that wants to modify the string, and expect your FancyString instance to reflect the modification.
jjav 6y ago
I think nearly every C programmer has gone through the phase of Oooh I'll write my own string library! Sure, that works. Except you have to call system libraries and all kinds of other external functions all of which naturally assume the conventional char arrays. So you spend a bunch of time converting back and forth until eventually realizing it's silly, just learn the convention and go with it.

TimTheTinker 6y ago

... except for libc, which apparently which is hardly ever questioned.

cycloptic 6y ago

There are a large number of those libraries. Every large C project eventually seems to grow its own string class.

user5994461 6y ago

>>> Surely someone could write a better string library in C that hides the complexity. In short, it's not possible to write a nice string library in C because C simply doesn't support objects, and by extension doesn't support libraries. Strings are a perfect example of an "object" in what is later known as object oriented programming. C doesn't have objects, it's the last mainstream language that's simply not object oriented at all, and that prevents from making things like a nice string library. If you're curious, the closest thing you will see in the C world is something like GTK, a massive C library including string and much more (it's more known as a GUI toolkit but there are many lower level building blocks). It's an absolute nightmare to use because everything is some abuse of void pointers and structs.

zlynx 6y ago
I think you mean GLib as seen here https://developer.gnome.org/glib/stable/glib-Strings.html https://developer.gnome.org/glib/stable/glib-Strings.html GLib and GTK are closely aligned parts of GNOME so they are easy to get mixed up.
- user5994461 6y ago
  Right. The string library is in glib. There were a few big libraries in the ecosystem if I remember well, GTK, glib and another two. They're from the same origin and often mixed together. It's been almost a decade since I dabbled into this stuff day-to-day. I think being forced to use glib is the turning point in a developer's life where you realize you simply have to move on to a more usable language.
  - Tteriffic 6y ago
    So true
c-cube 6y ago
Strings have nothing to do with objects. You can write a string library, eg. [sds](https://github.com/antirez/sds https://github.com/antirez/sds). It's just not standard.
- user5994461 6y ago
  The challenge is not to write a string library, but to write a "nice" string library. Let's say, something that's easier to use and doesn't have all the footguns of the char arrays. The library you link doesn't come anywhere close to that. It's 99% like the standard library and it has the exact same issues.
  - mariusor 6y ago
    I would love to see what you mean by "exact same issues". sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings. If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C ecosystem considers as strings. Keeping an API which is very similar to the standard library is also a plus, as it doesn't force developers to change the way they reason about the code.
    - CRConrad 6y ago
      > sds strings contain their lengths, so operating on them you don't have to rely on null termination, which (to my knowledge as a lower-midlevel C programmer) is the most prevalent reason why people take issue with C strings. Wait, haven't I seen that idea somewhere else...? > If you mean that they're not really "strings" but byte arrays I would say that I agree, but to all intents and purposes that's what the C ecosystem considers as strings. Aha, strings as byte arrays but with a built-in length marker. But yeah, Pascal is sooo outmoded and inferior to C... Sigh.
  - kergonath 6y ago
    You’re moving goalposts now. Just earlier you wrote that you couldn’t write a library in C because C does not support objects, not that you couldn’t write a nice library (for whatever definition of “nice” you want to use, which will be different from someone else’s). In fact there are several libraries for string-like objects; the main barrier to use them is that none of them is standard. You can at least acknowledge that before talking about nice-ness, which is a whole other point.
phlakaton 6y ago
What rubbish! You do not need objects to make a library. Structs, typedefs, and functions do just fine. There are even techniques in C to define abstract data types if you want! Take another look at https://developer.gnome.org/glib/stable/glib-Strings.html#g-string-new-len https://developer.gnome.org/glib/stable/glib-Strings.html#g-... . That’s all C, baby, and could be replicated in a completely independent strings-only library built on the standard library if you wished. The reasons no such library exists are ecological, not technical.

kelnos 6y ago

Because most projects involve interfacing with other third-party libraries that will undoubtedly not know about this other third-party library that implements a nice string.

kaba0 6y ago
It can contain a to_cstring() function and problem solved. If it uses a struct with length of string and pointer to a c-style string, even the conversion can be elided (at the price of some inflexibility/unnecessary copying while in use)
- kelnos 6y ago
  That would mean you lose the ability to do all sorts of optimizations and memory sharing. Or at least, you can do them, but then the c_string() function requires copying the data. And that also means that it's a one-way thing: you can't use the copy on something that wants to modify the string, and expect your FancyString instance to reflect the modification.

jjav 6y ago

I think nearly every C programmer has gone through the phase of Oooh I'll write my own string library! Sure, that works. Except you have to call system libraries and all kinds of other external functions all of which naturally assume the conventional char arrays. So you spend a bunch of time converting back and forth until eventually realizing it's silly, just learn the convention and go with it.