"Errors cannot be avoided by recipe. If they could, we could eliminate automobile accidents by plastering the countryside with Drive Carefully signs!" -- Andrew Koenig, _C Traps and Pitfalls_
Some of the article's examples come straight from that book, BTW.
is that quote meant seriously? certainly it's obvious that the analogy doesn't work. we do have signs plastered around the countryside that are recipes for driving, they just actually include the ingredients. i would think the same applies to code, but rather than recipes, to hold the analogy, you are providing templates for recipes, or maybe style guides for writing recipes. (bad analogy, imho.)
"Since function calls usually take a long time, getchar is often implemented as a macro."
And then I stopped reading. Does anyone know of a meaning for this sentence that's more sophisticated than "function call overhead is punishing, don't call functions if you can help it", advice that was out of date when C was /invented/, for God's sake? Something special about getchar(), maybe?
Um...function calls do have an overhead. Yes it is negligible in most cases but it certainly made a difference when C was invented.
In fact, C++ still carries the "inline" declaration around to avoid function call overhead. The compiler can ignore when knows better but the fact that inlining exits implies that function call overhead is not imaginary.
Generally, function call overhead is absolutely worth the added ability to abstract, but adding that overhead per character in all IO operations adds up quickly. Getchar is often the innermost loop of IO-bound processing, so inlining it (in this case, by making it a #define macro) is worth doing as a special case.
getc() and putc() can be implemented as macros in standard C (although a non-macro version needs to be supplied as well), so I think the author was trying to explain why getc() may appear slower in some circumstances than others.
Of course, nowadays, it would be difficult to measure the difference between a macro getc() and a function getc().
I like how gets() and scanf() are both considered unsuitable for use. There's something wrong with a language when you can't trust the standard library's input functions, and I say this as someone who rather likes C in the right context.
Where's the mention of the three-argument main() variation? (int argc, char argv, char env)? Is this not standard?
Some of the article's examples come straight from that book, BTW.