5 ms·

C is a great language- it let's you get down and dirty with the computer. However, the one huge downside to programming in C is having to deal with strings. L

C is a great language- it let's you get down and dirty with the computer. However, the one huge downside to programming in C is having to deal with strings. Let's face it, C strings are absolutely terrible. For such an important feature, the string implementation of null terminated char* is just miserable to work with. See: http://queue.acm.org/detail.cfm?id=2010365 http://queue.acm.org/detail.cfm?id=2010365

stusmall 13y ago
That is a problem with the stdlib and not so much the language. There is nothing stopping you from creating a more robust string implementation that stores size and does bounds checking for some operations(You can't easily/safely enforce anything like string immutablity at the language level... unless anyone out there can think of a way). I've seen it before, but not often. Usually the C code I'm working on does very little string manipulation and speed/size matters.
- i_c_b 13y ago
  Well, to be fair, strings are much nicer to work with when you have a suitable overload for '+', and that very much is a problem with C the language. Same goes for 3d vectors in C as well.
  - theseoafs 13y ago
    That's your opinion. I (and many other C programmers) find it refreshing that when I see a "+", a couple numbers are going to be added together. Nothing else could possibly happen, and I don't have to cross-reference the types of the operands to figure out whether a method in some far-off source file is going to be called.
    - i_c_b 13y ago
      C is willing to hide a lot of numeric type casting details about doubles vs floats vs unsigned ints vs chars behind the magic of the "+" character, so maybe you're willing to endure a lot more type-dependent compiler magic than you're letting on here, despite so graciously speaking for many other C programmers. In fact, "p+1" might very well mean "p+4" if p is an int. Or maybe it means "p+32" if p is a FILE (on my compiler). Or maybe it means... Wow! Wait a second! That seems pretty type dependent to me, come to think of it! But that's just my opinion.
      - theseoafs 13y ago
        Look back; I never said the + operator wasn't type dependent. It clearly is. It's certainly true in C that no matter what, the + operator adds two numbers together. The exact nature of that addition depends on the types of the operands, but the rules for that are dead-simple, and most importantly, aren't extensible; I can't include a header file that will change those simple rules. i.e. Once you understand how pointer arithmetic works, and you know how C's type promotion scheme works, the meaning of any addition expression is basically evident, and you have a few guarantees about the behavior of the program (for example, I can reasonably expect that my addition won't take more than a couple clock cycles, depending on what kind of casting needs to be done and the like). In languages that support operator overloading, + can literally mean anything.
        i_c_b 13y ago
        BUT clearly there is a world of difference between saying "it would be nice to have char* + char* as a short hand for string concatenation somehow" - which is roughly what I was saying - versus saying "all operators in a language should be arbitrarily overloadedable", which is roughly how you responded. Now, I'm not saying there is an obvious way to handle "char* + char" meaningfully or safely in C. But on the other hand, char stackString = "some literal"; is generally handled in an entirely different fashion from int myVar = 7; if both are declared as local stack variables - and C programmers generally have no problem learning that "=" is going to mean something quite special when declaring string literals this way, compared to other data types. Because as you say, it's just one more language rule. The only real places where I miss operator overloading in C are when dealing with strings in performance non-critical places, any time I'm using 3D vectors, and any time I'm writing matrix math. If those were handled as primitives in the language (and as the string literal example shows, C already does go partway down that road), I'd very happily part with arbitrary operator overloading.
        theseoafs 13y ago
        > char *stackString = "some literal"; Uh, in what way is that "entirely different" from the int declaration? In both cases, you're just copying a couple words from one place to another, which is what the = operator does. There's nothing "special" about that declaration; we're just writing a pointer into a variable on the stack. My feeling is that you're uncomfortable with C's treatment of strings because you don't entirely understand the memory model.
- vezzy-fnord 13y ago
  Indeed: http://bstring.sourceforge.net/ http://bstring.sourceforge.net/
stefantalpalaru 13y ago
You're not forced to use the standard library's strings. Take a look at GLib: https://developer.gnome.org/glib/2.37/glib-Strings.html https://developer.gnome.org/glib/2.37/glib-Strings.html
- RogerL 13y ago
  Yes, but no. Yes, as in of course you are correct. However, this is an argument that Bjarne often uses in the context of C++, and it drives me a bit batty. For example, he'll wax eloquent on how it is fine that there is no multidimensional array type built into the language, because look how easy it is to write one yourself, or use one somebody else wrote. And, at the first approximation, that is surely true. Heck, I'm taking time out to post this from working on a Kalman Filter class I wrote that uses a hand coded multidimensional array class. But, the problem is is that there are thousands of string libraries out there, and thousands of multidimensional arrays, and so on. And they don't play nicely with each other. Heck, we use char, std::string, CString, and QString all in the same project. You can guess the evolution - a bunch of old library code written 10 years ago who didn't trust/like the new-fangled std::string stuff. External library code written in C. Then code written in modern C++ with an aim to be portable (std::string). Then some MFC UI code, and more code written by MFC people that didn't care about strewing that dependency in places where it didn't belong. And now we are in Qt, and I have to really clamp down on the code reviews to keep QString from straying beyond the UI components. Ugh. Hey, I love C, and this is not a rant against the language. C strings have their place. I can't tell you how many times I've written code along the lines of: char* c = some_data(); c += header_size; name = extract (c, ','); You get the idea. At one time that was the state of the art way to do string processing without the cost of a lot of extra creation/deletion. You just use pointer arithmetic, move along a data source, scraping it as you go. But these days we aren't so interested in that kind of scraping, and are far more interested in higher level problems. And we have no standard to fall back on, in C. Sure, I can elect to use a third party library, under the almost never to be satisfied requirement that every line in our project is written in house, or that every third party library either uses the library I chose, or that it can inter-operate with it seamlessly. Frankly, I've never been in a situation where either of those held. So we end up either reverting to the mean (c strings), or making endless conversion calls to switch from one form to another.

stusmall 13y ago

That is a problem with the stdlib and not so much the language. There is nothing stopping you from creating a more robust string implementation that stores size and does bounds checking for some operations(You can't easily/safely enforce anything like string immutablity at the language level... unless anyone out there can think of a way). I've seen it before, but not often. Usually the C code I'm working on does very little string manipulation and speed/size matters.

i_c_b 13y ago
Well, to be fair, strings are much nicer to work with when you have a suitable overload for '+', and that very much is a problem with C the language. Same goes for 3d vectors in C as well.
- theseoafs 13y ago
  That's your opinion. I (and many other C programmers) find it refreshing that when I see a "+", a couple numbers are going to be added together. Nothing else could possibly happen, and I don't have to cross-reference the types of the operands to figure out whether a method in some far-off source file is going to be called.
  - i_c_b 13y ago
    C is willing to hide a lot of numeric type casting details about doubles vs floats vs unsigned ints vs chars behind the magic of the "+" character, so maybe you're willing to endure a lot more type-dependent compiler magic than you're letting on here, despite so graciously speaking for many other C programmers. In fact, "p+1" might very well mean "p+4" if p is an int. Or maybe it means "p+32" if p is a FILE (on my compiler). Or maybe it means... Wow! Wait a second! That seems pretty type dependent to me, come to think of it! But that's just my opinion.
    - theseoafs 13y ago
      Look back; I never said the + operator wasn't type dependent. It clearly is. It's certainly true in C that no matter what, the + operator adds two numbers together. The exact nature of that addition depends on the types of the operands, but the rules for that are dead-simple, and most importantly, aren't extensible; I can't include a header file that will change those simple rules. i.e. Once you understand how pointer arithmetic works, and you know how C's type promotion scheme works, the meaning of any addition expression is basically evident, and you have a few guarantees about the behavior of the program (for example, I can reasonably expect that my addition won't take more than a couple clock cycles, depending on what kind of casting needs to be done and the like). In languages that support operator overloading, + can literally mean anything.
      - i_c_b 13y ago
        BUT clearly there is a world of difference between saying "it would be nice to have char* + char* as a short hand for string concatenation somehow" - which is roughly what I was saying - versus saying "all operators in a language should be arbitrarily overloadedable", which is roughly how you responded. Now, I'm not saying there is an obvious way to handle "char* + char" meaningfully or safely in C. But on the other hand, char stackString = "some literal"; is generally handled in an entirely different fashion from int myVar = 7; if both are declared as local stack variables - and C programmers generally have no problem learning that "=" is going to mean something quite special when declaring string literals this way, compared to other data types. Because as you say, it's just one more language rule. The only real places where I miss operator overloading in C are when dealing with strings in performance non-critical places, any time I'm using 3D vectors, and any time I'm writing matrix math. If those were handled as primitives in the language (and as the string literal example shows, C already does go partway down that road), I'd very happily part with arbitrary operator overloading.
        theseoafs 13y ago
        > char *stackString = "some literal"; Uh, in what way is that "entirely different" from the int declaration? In both cases, you're just copying a couple words from one place to another, which is what the = operator does. There's nothing "special" about that declaration; we're just writing a pointer into a variable on the stack. My feeling is that you're uncomfortable with C's treatment of strings because you don't entirely understand the memory model.
vezzy-fnord 13y ago
Indeed: http://bstring.sourceforge.net/ http://bstring.sourceforge.net/

stefantalpalaru 13y ago

You're not forced to use the standard library's strings. Take a look at GLib: https://developer.gnome.org/glib/2.37/glib-Strings.html https://developer.gnome.org/glib/2.37/glib-Strings.html

RogerL 13y ago
Yes, but no. Yes, as in of course you are correct. However, this is an argument that Bjarne often uses in the context of C++, and it drives me a bit batty. For example, he'll wax eloquent on how it is fine that there is no multidimensional array type built into the language, because look how easy it is to write one yourself, or use one somebody else wrote. And, at the first approximation, that is surely true. Heck, I'm taking time out to post this from working on a Kalman Filter class I wrote that uses a hand coded multidimensional array class. But, the problem is is that there are thousands of string libraries out there, and thousands of multidimensional arrays, and so on. And they don't play nicely with each other. Heck, we use char, std::string, CString, and QString all in the same project. You can guess the evolution - a bunch of old library code written 10 years ago who didn't trust/like the new-fangled std::string stuff. External library code written in C. Then code written in modern C++ with an aim to be portable (std::string). Then some MFC UI code, and more code written by MFC people that didn't care about strewing that dependency in places where it didn't belong. And now we are in Qt, and I have to really clamp down on the code reviews to keep QString from straying beyond the UI components. Ugh. Hey, I love C, and this is not a rant against the language. C strings have their place. I can't tell you how many times I've written code along the lines of: char* c = some_data(); c += header_size; name = extract (c, ','); You get the idea. At one time that was the state of the art way to do string processing without the cost of a lot of extra creation/deletion. You just use pointer arithmetic, move along a data source, scraping it as you go. But these days we aren't so interested in that kind of scraping, and are far more interested in higher level problems. And we have no standard to fall back on, in C. Sure, I can elect to use a third party library, under the almost never to be satisfied requirement that every line in our project is written in house, or that every third party library either uses the library I chose, or that it can inter-operate with it seamlessly. Frankly, I've never been in a situation where either of those held. So we end up either reverting to the mean (c strings), or making endless conversion calls to switch from one form to another.