K
Kamilche
You know, all this furor over this book caused me to go look it up on
Amazon. I've never read this book... but from what I can see from the
legally available table of contents, excerpt, and index at Amazon, it
looks more like a "Teach me newbie C" book than a "UNCOVER DEEP
MYSTERIES OF C!!" sort of affair.
I've got a better idea! Let's discuss some 'Deep C Secrets' of our
own! I'll start.
Testing - If you haven't tested to prove it right, it can almost
certainly be proven to be WRONG. It's terribly easy to screw
something up in C, causing buffer overruns and undefined behavior.
It's gotten to the point where I don't feel comfortable calling coding
done until the tests are written. There's too many places C can bite
you.
I wasn't this paranoid in other programming languages... you know, the
ones that take 1/10 the time to write, and run 100x slower, like VB.
Because you didn't have fine-grained control over the code, there were
fewer places to screw up something fundamental. But you paid for it in
loss of control, loss of speed, and a less stable development
environment, because you had to rely on OTHER programmer's buggy code.
If it's YOUR buggy code, you at least have a fighting chance of
figuring out what's wrong with it and fixing it.
Uh, look there. A pearl of wisdom! Grab it and start your OWN book.
Amazon. I've never read this book... but from what I can see from the
legally available table of contents, excerpt, and index at Amazon, it
looks more like a "Teach me newbie C" book than a "UNCOVER DEEP
MYSTERIES OF C!!" sort of affair.
I've got a better idea! Let's discuss some 'Deep C Secrets' of our
own! I'll start.
Testing - If you haven't tested to prove it right, it can almost
certainly be proven to be WRONG. It's terribly easy to screw
something up in C, causing buffer overruns and undefined behavior.
It's gotten to the point where I don't feel comfortable calling coding
done until the tests are written. There's too many places C can bite
you.
I wasn't this paranoid in other programming languages... you know, the
ones that take 1/10 the time to write, and run 100x slower, like VB.
Because you didn't have fine-grained control over the code, there were
fewer places to screw up something fundamental. But you paid for it in
loss of control, loss of speed, and a less stable development
environment, because you had to rely on OTHER programmer's buggy code.
If it's YOUR buggy code, you at least have a fighting chance of
figuring out what's wrong with it and fixing it.
Uh, look there. A pearl of wisdom! Grab it and start your OWN book.