maybe the biggest improvement in c programming over the last decade is valgrind, making purify-like debugging available to everyone. it's completely removed a whole class of annoyingly hard to fix bugs from my code.
C made lots of sense in the context it was developed, but the world would be better if we had safer systems programming languages.
Valgrind, purify and friends are required to C, the same way Java requires IDEs, to improve language usability.
Have said this, the new trend in having static analysis tools integrated in the development process, like Clang, Eclipse CODA, Visual Studio's tools or HP Code Advisor, among others, can bring a bit more safety into C.
We have "safer" languages but our systems and tools remain in C. Given the intense competition in software, there must be solid reasons C remains the foundation of computing.
"Skilled C programmers do not need profilers, bounds checkers and memory leak detectors."
Skilled programmers use profilers because the alternative (guessing) is a poor strategy for diagnosing poor performance. And no skilled programmer would spurn a useful tool like a bounds checker or memory leak detector, because nobody is perfect and these tools save immense amounts of time by pointing you straight to the problem.
Programmers who don't use profilers write slow programs (even though they spend many hours "optimizing" them).
Sadly you don't find many of them in the enterprise world, specially when dealing with off-shoring companies. :(
> ... Given the intense competition in software, there must be solid reasons C remains the foundation of computing.
Because it is dumb to code everything new, just because another language is cooler, nicer, safer, etc. So existing software keeps being coded in C.
Even if I expressed my opinion the way I did, I will surely pick C if it makes sense for the project at hand.
- Donald Knuth (wrote a study on profilers)
- Rob Pike (wrote a profiler, 'though for FORTRAN)
- Brian Kernighan (used a profiler to double the speed of his AWK interpreter)
I wonder who you consider a skilled C programmer, if not K from K&R.
Why attack C at all? Why not instead convince us of the merits of another language?
There are great tools around. I agree with that. Which parts of Clang do you like best?
The re-factoring support and modules extensions are also a welcome additions.
And that's without the commercial tools such as Coverity.
Some people actually had the gall to complain about him ensuring the noobies learned to use valgrind before proceeding to write any real code.
Ingrateful dipshits don't remember what the pre-valgrind/dtrace days were like.
Last time I wrote anything in C was on Netware NLMs, and it has been long enough that I have mostly forgotten what I knew.
i don't know if you know the book - an older copy is on my desk and it use it regularly when working in c - but it's part introduction and part informed guide to the libraries. it's not a "friendly" book (it's not for "dummies"), but it's well written and surprisingly compact for all it contains (at least, the copy i have is; i am waiting for delivery of the latest version).
If you don't believe me, just run Valgrind on random sampling of C programs that didn't use such a tool - I reckon it will find issues with most of them.
I do not necessarily abide by this point of view, but I do respect the kind of harsh discipline it advocates. Valgrind is definitely useful, really useful, but great C programs (and programmers) existed long before it appeared.
(valgrind's lack of availability is a bit of a problem. I'm not complaining - I bet it is a bit fiddly to port it to a new system - but it's very easy to never have come across any system that can run it in your professional life. So being able to work without it is no waste of time.)
Uninitialised data and memory scribbles can be tricky to detect 100% reliably without valgrind, but if you code appropriately, you'll spot it. Leaks are very easy to find (fixing them, not always so much), and I don't really understand why one needs this monster program to discover them - but maybe one day I'll actually be in a position to use it, and I'll find out what I'm missing.