Be Const-Correct

Home Blog Talks Books & Articles Training & Consulting

Prev
Up
Next

On the
blog
RSS feed November 4: Other Concurrency Sessions at PDC
November 3
: PDC'09: Tutorial & Panel
October 26: Hoare on Testing
October 23
: Deprecating export Considered for ISO C++0x

This is the original article substantially as first published. See the book Exceptional C++ (Addison-Wesley, 2000) for the most current version of this article. The versions in the book have been revised and expanded since their initial appearance in print. The book versions also incorporate corrections, new material, and conformance to the final ANSI/ISO C++ standard.

Advice From the C++ Experts: Be Const-Correct

This article appeared in C++ Report, 10(9), October 1998.

 

Be const-correct: const and mutable are your friends.

I still sometimes come across programmers who think const isn't worth the trouble. "Aw, const is a pain to write everywhere," I've heard some complain. "If I use it in one place, I have to use it all the time. And anyway, other people skip it, and their programs work fine. Some of the libraries that I use aren't const-correct either. Is const worth it?"

We could imagine a similar scene, this time at a rifle range: "Aw, this gun's safety is a pain to set all the time. And anyway, some other people don't use it either, and some of them haven't shot their own feet off..."

Safety-incorrect riflemen are not long for this world. Nor are const-incorrect programmers, carpenters who don't have time for hard-hats, and electricians who don't have time to identify the live wire. There is no excuse for ignoring the safety mechanisms provided with a product, and there is particularly no excuse for programmers too lazy to write const-correct code. (Perhaps not strangely, the same people who skip const tend to ignore compiler warnings, too. Illuminating, that.) In many development shops, skipping const and ignoring compiler warnings are "one-warning" offenses, and rightly so.

Using const whenever possible makes for safer, cleaner code. It lets you document interfaces and invariants far more effectively than a mere /* I promise not to change this */. It's a powerful part of "design by contract." It helps the compiler to stop you from accidentally writing bad code. It can even help the compiler generate tighter, faster, smaller code. That being the case, there's no reason why you shouldn't use it as much as possible, and every reason why you should.

It's true that not all library interfaces are const-correct. That isn't an excuse for you to write const-incorrect code, though. (It is, however, one of the few good excuses to write const_cast.) Always make your own code const-correct, and when you call the broken library you can use the appropriate casts wherever necessary -- preferably with a detailed comment nearby grumbling about the library vendor's laziness and how you're looking for a replacement product.

If you still harbor any doubts about const, run (don't walk) and reread Item 21 in Scott Meyers' influential book Effective C++ ("Use const whenever possible"). It's for good reason that the C language has had const since the pre-standardization days. Back in the early 1980s, see, a researcher named Stroustrup had designed this funny little language called C with Classes, which had a funny little keyword called readonly that was demonstrably useful for specifying cleaner interfaces and, therefore, writing safer code. The C folks at Bell Labs liked the idea, but preferred the name const; when the ANSI C committee got rolling a short time later they adopted the same feature with the same name... and the rest, as they say, is history.

Don't shoot yourself (or your fellow programmers!) in the foot. Always check your safety latch: Be const-correct. Write const whenever possible, and smile at the thought of cleaner, safer, tighter code.

Copyright 2009 Herb Sutter