Sponsored Link •
Scott Meyers, C++ expert and author of numerous books, including Effective C++, talks with Bill Venners about the utility of const, the appropriate time to use RTTI, a good attitude about efficiency, and his current quest for general programming principles.
Scott Meyers is one of the world's foremost experts on C++ software development. He wrote the best-selling Effective C++ series (Addison-Wesley): Effective C++ (1997), More Effective C++ (1995), and Effective STL (2001); wrote and designed the Effective C++ CD; is consulting editor for Addison-Wesley's Effective Software Development Series; and is a member of the advisory board for Software Development magazine. A programmer since 1972, Meyers holds an M.S. in computer science from Stanford University and a Ph.D. from Brown University.
In this four-part interview, which is being published in weekly installments, Meyers gives his views on many object-oriented design topics:
interface, and points out a schism in the focus of the C++ and other prominent development communities.
Bill Venners: One of your guidelines in Effective C++ is, "Use const wherever possible." I followed this guideline for a while when I programmed in C++, but I always felt I was typing a lot without getting much benefit. In Java, I don't use final wherever possible. For example, I usually don't declare method parameters final, even if I think they should never be changed. The reason is that 99.9 percent of the time they don't get changed anyway, so I don't feel typing const or final all those times is worth the benefit. Had you ever heard that feedback before?
Scott Meyers: Actually, I've never heard that particular argument before. Const is an insurance policy. It's a way of saying to the compiler, "Don't let me change this, because I'm not supposed to change it." Is the insurance worth the premiums? You're saying in your experience, the cost of the policy to type const all those times just doesn't pay for itself. If that's been your experience, then that's fine.
Everybody I have talked to about const has told me essentially the same story. It is possible the stories have sought me out. I'm not saying this is a random sample. The story basically goes like this: Our system was not const correct. We didn't use const, so we decided to add const. It was a hellish nightmare to do it, because const propagates all over the place. You can't just fix it in one place. You have to fix it throughout the entire system. Everybody said they found a few places where they were modifying things that were never supposed to be modified. So they actually did track down logic errors.
Now one can wonder how serious the logic errors were if they never caught them in testing. One might also question how good their testing was. Nevertheless, people who have used const in large systems have reported that they had identified places where they would have violated a design constraint. I'm still a big believer in const, because I think typing those six characters just isn't that hard to do.