Good Reading
Posted in C++ on Sun, June 1, 2008 at 11:07 PMAs a huge fan of C++, I'm always interested in learning new things from people that have been much more involved with the language over the years than I have. I've been subscribing to a couple of blogs for some time now that have been very educational, and I thought I'd share.
Herb Sutter
Herb Sutter is currently the chair of the ISO C++ standards committee and has been involved with the C++ standardization process for quite some time (if not the entire time). As such, he's incredibly expert and reading his work is always enjoyable.
Recently his writings have focused on concurrency issues. He's got a whole series of articles on synchronization, multi-processing, etc. that have been published on Dr. Dobb's Journal (you can find links to the articles on his blog).
In addition, his non-blog website is also great reading, especially his old (but still relevant) series Guru of the Week. He's got a lot of really great gems in there and it's really worth reading through all of them in my opinion.
Andrew Koenig
Andrew Koenig has also been involved in the standardization process, and is the father of argument dependent name lookup in C++, which is also known as "Koenig lookup."
He tends to write more about C++ and programming philosophy in general, and doesn't get into the nitty gritty like Herb Sutter. Nevertheless, still interesting reading.
Enjoy!
6 comments:
I just read through some of those and they're definitely interesting reads, but I have to say that I just don't agree with Andrew Koenig's statements on testing and compiler warnings. Maybe I'm missing something, but they just don't seem all that well thought out.
However, having said that I had never even heard of (or even thought of) argument dependent name lookup before. I'm just grateful that there are smart guys out there to think of this stuff so the little things that I take for granted in C++ are there to make it "just work".
Yeah, some of Koenig's stuff sounds pretty wonky at first. I actually went back and re-read his posts on testing and compiler warnings as a result of your comment, and this time around I couldn't really find anything I disagree with strongly.
For instance, in his testing article he talks about memory leaks. I've basically taken his same approach--code using safe C++ practices. I've never done testing specifically to find memory leaks. I probably should, because testing isn't bad, but it reminds me of the famous quote by Donald Knuth, in relation to a certain piece of code he wrote: "I've only proven that it works, I haven't tested it."
Warnings are a whole separate beast. In general I try to get rid of all compiler warnings. Interestingly enough, in Visual Studio 2005, 64-bit compatibility warnings were enabled by default. For some reason they are not only disabled by default, but also deprecated, in Visual Studio 2008. I always hated those things in 2005...
I agree that testing can be hard to really tackle/wrap your head around, but I guess I just felt that most of his examples were pretty lame (the floating point number is not "impossible" like he claims. Yes, I realize that it quickly becomes untractable as it moves towards a non-trivial problem, but I'm still bothered by people making absolute claims that just aren't true). But just because testing is difficult or hard to quantify/qualify doesn't mean that it doesn't have any merit.
I also just can't buy into the warnings thing, because if a certain warning really bothers you, then just disable it. Yes, I realize that it can become annoying to have to always go in and disable a list of warnings, but I have never felt that coding to not have any warnings has ever constrained me to a "subset of the language". And it's also odd that both you and him use the "use good coding standards" logic when talking about preventing memory leaks, but for some reason that doesn't apply to warnings. Maybe I just haven't done anything exotic enough for his argument to make sense to me, but I just don't get what the big deal is.
Also, the blog of Koenig's that you linked to has been deprecated and the current one is here.
I've never really investigated the floating point testing issue myself, but I have heard other people, including professors at BYU, state that it's impossible to test arithmetic on every possible combination of floating point numbers in a reasonable amount of time (i.e. the average lifespan of a human). In fact, after a quick Google search, I pulled up this article that states testing a certain binary operation on every possible combination of two 32-bit floats would take over 136 years.
I think people are relatively confident that they've discovered classifications of numbers, at least as far as IEEE floating point numbers are concerned, that make testing more practical. However, I think that's exactly what Koenig was arguing: a lot of problems are impossible to test exhaustively, and you have to resort to finding classifications and edge cases, which can be hard. I guess what I take away from it is that you shouldn't rely exclusively on testing to find problems--you need to do everything possible to make sure bugs are never introduced to begin with.
As for the warnings, I'm not completely sold. Like I said, I code to eliminate warnings, which I think was exactly what he was arguing against. I definitely agree that good coding standards are very useful for warnings, but even running code through Visual C++ and GCC will turn up vastly different output as far as warnings are concerned. I guess I'm an extremist because I usually run my code through multiple compilers on purpose just to make sure everybody is happy, so Koenig would probably frown on me.
Anyway, I'm not particularly sold on everything he says, but it does make interesting food for thought. Herb Sutter is probably my favorite just because he focuses more on really concrete technical things. I really wish Bjarne Stroustrup had a blog.
Oh, and thanks for the new link to Koenig's blog. I had no idea!
Oh yeah, I forgot to point out that I really disagreed with Koenig's post on
std::vector. Anyway...I realize that all of this is 'academic', but what took 136 years almost 10 years ago would take less than 1/4 of the time. And with a problem like that why can't you just run 100 or 1000 of the units in parallel? I know that's difficult (if not impossible), but I think that the real problem is what you've already pointed out "how do you generate truth?".
What post about std::vector are you referring to? This one? I thought that one was pointlessing degrading and rude.