71–80 of 178 posts
Earlier quoted context omitted.
>it is a bit weird to say they are null-terminated Yeah, it would be. They're NUL-terminated.
Unfortunately, "null-terminated", although incorrect, is widely used. :( http://googlefight.com/index.php?lang=en_GB&word1=%22nul... I hate all the variations of nothing. undef, null, NULL, NIL, NUL...
I wonder if I'm alone in thinking that the original `while` version is easier to read and understand than the ending `for` version. I've never quite understood C programmers' love of the `for` loop. It's just a `while` loop with the different parts stuck in different places (`init; while (cond) { ...; inc; }` is the same as `for(init; cond; inc) { ...; }`) and it doesn't (at least for me) result in any greater clarit…
I think for loops are better than while loops for looping over arrays. I'll try and explain my reasoning: Whenever you see a `for` loop, it tells you something that a `while` loop doesn't. It tells you the kind of loop you're about to do. A `for` (usually) means you're going to be looping over an array, with a specific length, with a specific "step" (usually one). This is information you immediately get by seeing a `…
Earlier quoted context omitted.
If you truly think the market for C developers is so favorable to employers that someone who can write the in-place-whitespace-removal function off the top of their heads is easy to find, then by all means, ding candidates for their spelling during interviews. Thanks for making it that much easier for the rest of us to hire. In the industry I work in --- computer software --- it is ludicrously hard to find people com…
I personally would count that against any candidate during an interview. I wouldn't necessarily reject them, but I would definitely count that against them. I work in Toronto, Ontario. English is not my native language, but I always do my best to ensure that my code or documentation is as close to crystal clear as possible. This starts with using correct spelling. Code is written first for humans to read, and to me m…
It reminds me of people who say they would never hire a developer who doesn't write comments. Really? Writing comments is a precious skill that takes years to develop? You just tell someone, if you work here, you need to write comments. Problem solved in one sentence. Same with variable names. Its a standards issue, nothing more, nothing less.
I wonder if I'm alone in thinking that the original `while` version is easier to read and understand than the ending `for` version. I've never quite understood C programmers' love of the `for` loop. It's just a `while` loop with the different parts stuck in different places (`init; while (cond) { ...; inc; }` is the same as `for(init; cond; inc) { ...; }`) and it doesn't (at least for me) result in any greater clarit…
I think for loops are better than while loops for looping over arrays. I'll try and explain my reasoning: Whenever you see a `for` loop, it tells you something that a `while` loop doesn't. It tells you the kind of loop you're about to do. A `for` (usually) means you're going to be looping over an array, with a specific length, with a specific "step" (usually one). This is information you immediately get by seeing a `…
I won't disagree with that in theory, but I don't really think the "for" loop is the solution. The real solution, I think, is a "foreach" construct (whether it's a loop built into the language (á la Java/C#) or a higher-order function (á la C++'s std::for_each), I don't really care) for iterating over arrays and other collections.
In practice, I think the for loop is too often abused for too little gain, and I think C would be a better language without it.
As an aside, I wonder if anyone has provided a suitable Hoare triple for C's for loop. I have an idea of what it would look like, but would love to see someone else's efforts to verify my own internalized one.
Interesting, when I solved the problem originally on my own, I got to the exact same solution just with different variable names and braces. I suspect that this is probably the most common way to solve it.
Yeah, I had almost exactly the same code. I'm sure most people did too. The only other "obvious" algorithm is the n^2 one.
Edit: Correction... I also copy the '\0' character before exiting instead of making that a separate step. It has to do with the order of things. Here is the code:
char* read_ptr = s;
do {
if (*read_ptr != c) {
*s++ = *read_ptr;
}
} while (*read_ptr++ != '\0');Earlier quoted context omitted.
Unfortunately, "null-terminated", although incorrect, is widely used. :( http://googlefight.com/index.php?lang=en_GB&word1=%22nul... I hate all the variations of nothing. undef, null, NULL, NIL, NUL...
How can "null-terminated" be incorrect when that is the language used by the C standard?
The character shorthand is "NUL", but the full name is "null". I still stand by my (silly semantic) point that the use of NULL is overloaded here. NULL is a pointer value, not a character value. The string does not terminate at a pointer; it terminates with a magic character. This has, in fact, bitten me in the past where '\0' was a legitimate member of my string, and I have to write my own accessors.
I always end up using perl when I have to do string manipulations and have let my c skills suffer as a result. Sad. Using perl regexp kills brain cells. #!/usr/bin/perl $in = ; $remove = ; chomp ($remove); chomp ($in); $in =~ s/$remove//g;
Bad boy! >hello|goodbye >| >>Result is 'hello|goodbye' >That's a nice dog you have there. >. >>Result is '' I usually handle this with: my $pattern = '\\'.substr($in,0,1); $in =~ s/$pattern//g; but it still doesn't feel safe. String operations in perl usually do what you want, but be careful with them!
$in =~ s/\Q$remove\E//g;
I always end up using perl when I have to do string manipulations and have let my c skills suffer as a result. Sad. Using perl regexp kills brain cells. #!/usr/bin/perl $in = ; $remove = ; chomp ($remove); chomp ($in); $in =~ s/$remove//g;
Bad boy! >hello|goodbye >| >>Result is 'hello|goodbye' >That's a nice dog you have there. >. >>Result is '' I usually handle this with: my $pattern = '\\'.substr($in,0,1); $in =~ s/$pattern//g; but it still doesn't feel safe. String operations in perl usually do what you want, but be careful with them!
I'm nowhere near an experience C coder, but doesn't the in place part mean that you don't create any additional variables or strings and just modify z_terminated? Is that even possible? This is an honest question, because the solution is obvious this way, but a bit harder if you can't create additional variables.
But z_terminated is a pointer to a lump of memory that contains bytes. In that context "in-place" means that you move things around in the lump of memory you are given (the one pointed to by z_terminated) rather than allocating some more memory and using that.
If I'm right, your misconception is by no means unique, but it's a dangerous one that shows that you don't understand what's going on in C with regards pointers, memory and strings.
If I'm wrong then I apologise.