C++ FAQ Celebrating Twenty-One Years of the C++ FAQ!!!
(Click here for a personal note from Marshall Cline.)
Section 18:
18.1 What is "const correctness"?
18.2 How is "const correctness" related to ordinary type safety?
18.3 Should I try to get things const correct "sooner" or "later"?
18.4 What does "Fred const* p" mean?
18.5 Difference between "Fred const* p", "Fred* const p" and "Fred const* const p"?
18.6 What does "Fred const& x" mean?
18.7 Does "Fred& const x" make any sense?
18.8 What does "const X& x" mean?
18.9 What does "const X* x" mean?
18.10 What is a "const member function"?
18.11 Using return-by-reference in a const member function?
18.12 What's the deal with "const-overloading"?
18.13 How a const member function can make an "invisible" change to a data member?
18.14 Does const_cast mean lost optimization opportunities?
18.15 Binding a pointer-to-const to a non-const object?
18.16 Does "Fred const* p" mean that *p can't change?
18.17 Errors trying to convert Foo** → Foo const**?
[18.3] Should I try to get things const correct "sooner" or "later"?

At the very, very, very beginning.

Back-patching const correctness results in a snowball effect: every const you add "over here" requires four more to be added "over there."