Skip to main content
Arduino

Return to Answer

added 186 characters in body
Source Link
Steve Summit
Steve Summit
  • 131
  • 3

C has no first-class string type. In pure C, if you want to manipulate strings, you have to use some combination of char [] arrays and char * pointers. You have to remember to allocate enough memory to hold the strings you're working with today. In many cases you can't assign strings; you may have to call strcpy or the like. In most cases you can't directly compare strings; you usually have to call strcmp or the like. This can all be a real nuisance, and if you get the details wrong, you get strange bugs and crashes.

C has no first-class string type. In pure C, if you want to manipulate strings, you have to use some combination of char [] arrays and char * pointers. You have to remember to allocate enough memory to hold the strings you're working with today. This can be a real nuisance, and if you get the details wrong, you get strange bugs and crashes.

C has no first-class string type. In pure C, if you want to manipulate strings, you have to use some combination of char [] arrays and char * pointers. You have to remember to allocate enough memory to hold the strings you're working with today. In many cases you can't assign strings; you may have to call strcpy or the like. In most cases you can't directly compare strings; you usually have to call strcmp or the like. This can all be a real nuisance, and if you get the details wrong, you get strange bugs and crashes.

added 1277 characters in body
Source Link
Steve Summit
Steve Summit
  • 131
  • 3

But there's a very good reason truethat plain C doesn't have such a type. Manipulating strings is just plain harder than manipulating ints or floats. The reason it's harder is precisely because they're variable-length, and potentially rather large. Under C's low-level philosophy, the best person to make good tradeoffs when it comes to deciding how to handle a particular program's strings is that program's author, not the compiler or library writer.

You can write a decently good, decently efficient, high-level, first-class string type. But, it's never going to be as efficient, for every problem, as handcrafted char [] and char ** code would be. Or Also, if there are a bunch of rules for how to use a first-class string type efficiently, avoiding fragmentation and the like, those rules are probably going to end up being almost as complicated as the runesrules for using char [] and char * correctly -- but the whole point of introducing the first-class string type was so that programmers wouldn't have to worry about those low-level details all the time! It's really rather a pretty pickle.

So when someone says, "you shouldn't use that high-level string type, it's wasteful and inefficient", the question to ask is, is it unacceptably wasteful or inefficient?

Once upon a time, people said we shouldn't use compiled languages, since they're wasteful and inefficient. Those people thought we should all write everything in assembly language. (And there are still a few people who say this.) Most of the time, though, we've discovered that compiled code is adequately efficient, and its other advantages more than make up for any slight lingering inefficiencies.

And the question for C strings versus Strings is almost perfectly equivalent. If your program is making significant use of strings, expending a large fraction of its time or a large fraction of the available memory towards them, the inefficiencies of Strings might well be unacceptable. If there are relatively few strings, however, the convenience to the programmer of using a high-level String type (along with the absence of bugs) might be well worth it, and the costs might be inconsequential.

But there's no one right answer to the question of "Do or don't use Strings", because it's a subjective question, and different people under different circumstances will legitimately come to different conclusions.

But there's a very good reason true C doesn't have such a type. Manipulating strings is just plain harder than manipulating ints or floats. The reason it's harder is precisely because they're variable-length, and potentially rather large. Under C's philosophy, the best person to make good tradeoffs when it comes to deciding to handle a particular program's strings is that program's author, not the compiler or library writer.

You can write a decently good, decently efficient, high-level, first-class string type. But, it's never going to be as efficient, for every problem, as handcrafted char [] and char ** code would be. Or, if there are a bunch of rules for how to use a first-class string type efficiently, avoiding fragmentation and the like, those rules are probably going to end up being almost as complicated as the runes for using char [] and char * correctly -- but the whole point of introducing the first-class string type was so that programmers wouldn't have to worry about those low-level details all the time! It's really rather a pretty pickle.

But there's a very good reason that plain C doesn't have such a type. Manipulating strings is just plain harder than manipulating ints or floats. The reason it's harder is precisely because they're variable-length, and potentially rather large. Under C's low-level philosophy, the best person to make good tradeoffs when it comes to deciding how to handle a particular program's strings is that program's author, not the compiler or library writer.

You can write a decently good, decently efficient, high-level, first-class string type. But, it's never going to be as efficient, for every problem, as handcrafted char [] and char ** code would be. Also, if there are a bunch of rules for how to use a first-class string type efficiently, avoiding fragmentation and the like, those rules are probably going to end up being almost as complicated as the rules for using char [] and char * correctly -- but the whole point of introducing the first-class string type was so that programmers wouldn't have to worry about those low-level details all the time! It's really rather a pretty pickle.

So when someone says, "you shouldn't use that high-level string type, it's wasteful and inefficient", the question to ask is, is it unacceptably wasteful or inefficient?

Once upon a time, people said we shouldn't use compiled languages, since they're wasteful and inefficient. Those people thought we should all write everything in assembly language. (And there are still a few people who say this.) Most of the time, though, we've discovered that compiled code is adequately efficient, and its other advantages more than make up for any slight lingering inefficiencies.

And the question for C strings versus Strings is almost perfectly equivalent. If your program is making significant use of strings, expending a large fraction of its time or a large fraction of the available memory towards them, the inefficiencies of Strings might well be unacceptable. If there are relatively few strings, however, the convenience to the programmer of using a high-level String type (along with the absence of bugs) might be well worth it, and the costs might be inconsequential.

But there's no one right answer to the question of "Do or don't use Strings", because it's a subjective question, and different people under different circumstances will legitimately come to different conclusions.

Source Link
Steve Summit
Steve Summit
  • 131
  • 3

I'm not an Arduino programmer, but I am a C programmer. And the problem of string types in C -- or, rather, the absence of a first-class string type in C -- is an old but important one.

The fundamental problem is this. In C, you can say things like

int a, b, c, d, f();
a = b + c;
d = f();

And you can say things like

float q, r, s, t();
q = r / s + t();

But you can not say

string x, y, z();
x = y + z();

C has no first-class string type. In pure C, if you want to manipulate strings, you have to use some combination of char [] arrays and char * pointers. You have to remember to allocate enough memory to hold the strings you're working with today. This can be a real nuisance, and if you get the details wrong, you get strange bugs and crashes.

So, especially if you're a beginning or casual programmer, It Would Be Nice if C had a true, first-class string type. (And of course C++ does have such a type.)

But there's a very good reason true C doesn't have such a type. Manipulating strings is just plain harder than manipulating ints or floats. The reason it's harder is precisely because they're variable-length, and potentially rather large. Under C's philosophy, the best person to make good tradeoffs when it comes to deciding to handle a particular program's strings is that program's author, not the compiler or library writer.

You can write a decently good, decently efficient, high-level, first-class string type. But, it's never going to be as efficient, for every problem, as handcrafted char [] and char ** code would be. Or, if there are a bunch of rules for how to use a first-class string type efficiently, avoiding fragmentation and the like, those rules are probably going to end up being almost as complicated as the runes for using char [] and char * correctly -- but the whole point of introducing the first-class string type was so that programmers wouldn't have to worry about those low-level details all the time! It's really rather a pretty pickle.