One of two CeePlusPlus strategies for dealing with the ConstQualifier; the other is to practice ConstCorrectness.  

When we avoid const completely, we '''never''' (OK, almost never) use the ConstQualifier in C++ programs as a modifier of a pointer or reference, save for the minimal set of cases where we have to use const to deal with language/library compatibility, or if necessary for an EmbeddedSystem (like data structures being in ROM).  

Uses of const that act like Java's final keyword--declaring a local variable or class member to be of type "const int", are OK--most such variables are never (or rarely) aliased and thus don't suffer from the const propagation problem (See below).  

Reasons to AvoidConstCompletely:

* ConstIsaVirus.  Declare a pointer/reference to be const; and the TransitiveClosure of places that pointer/reference is passed will also need to be declared const.  Or else you'll need to cast away const, and that's often a bug waiting to happen.
** ConstIsaVirus is annoying when one has to make lots of edits by hand due to the ripple effect, but that nuisance is a small thing compared with the increment of correct behavior that is thereby guaranteed at compile time when used correctly, as with any kind of static type checking. Changing an int to a float is precisely as virus-like in its ripple effect.
** If casting away const leads to bugs, then avoiding const altogether quite obviously leads to the same bugs and more.
*** ''Um, yeah, unless you rely on TestDrivenDevelopment to eliminate those bugs rather than fallible old compilers. And if you don't, then wtf?''
**** You could use the same (flawed) argument against using static typing.  A typechecker, including one that supports const, is a proof system for program correctness.  Automated tests also prove program correctness, but if you're writing unit tests to prove things that the compiler could prove for you, you're wasting time.  Let the compiler prove everything it can, so you can focus your unit testing effort on more interesting aspects of functionality.

* const promises very little.  Const is ''not'' a synonym with "immutable"; all const means is "you can't change the object through this pointer/reference, and any place this pointer/reference is copied".  There ''can'' be, of course, non-const pointers to the object which ''can'' mutate the object.  (And of course, you can always ''create'' such a pointer with by CastingAwayConst).  The most useful use of const--declaring that a given reference will not be rebound--is handled better by final in JavaLanguage and others, and doesn't suffer from the virus problem.  
** In limited situations it is synonymous with immutable, and those situations are useful ones.
** ''Insufficient ROI. Const is PrematureOptimization of the design. Seriously, how do '''you''' know what someone else will want to do with your class?''
*** The idea is to NarrowTheInterface.  Don't put mutability in your interface if YouArentGonnaNeedIt.  As a thought experiment, consider what policy you'd adopt of const were the default, and you needed to explicitly make things non-const; would you then argue against making things non-const because ''that'' is PrematureOptimization?

* You don't have to worry about:
** overloading const (where two functions are written that do the same thing, one with an all-const signature and one without, just because one or more arguments--including possibly the ThisPointer--is returned as a result).
** const_iterator--truly a bletcherous wart on the backside of the StandardTemplateLibrary.  (Of course, some consider the STL a bletcherous wart on the backside of C++, and others consider C++ a bletcherous wart on the back side of ComputerScience--so that would make const_iterator a ThirdDegreeWart).
*** Yet others argue that STL is the best part, other than being based on bletcherous C++ templates, and that C++ is a bletcherous wart on the back side of STL. ;-)
** MutableKeyword, and the whole PhysicalConst vs LogicalConst issue.

* The ConstQualifier's main purpose is HelpingTheCompiler; it has almost ''zero'' use in describing the user's problem.
** False for 2 reasons. First, HelpingTheCompiler is about language design issues, and largely does not apply once you've chosen a language. Secondly, const is not much different from other type annotations in C++, and as such is useful in communicating one's intentions to the compiler so as to receive compile-time type safety guarantees, typically a good thing.
** ''No, it's a lousy thing because it encourages test-last. ConstCorrectness is a kind of cult in which the holy C++ compiler will magically save you from bugs. Except it can't, doesn't, and won't. TDD, and only TDD, can magically save you from bugs.'' You're wrong.  TestDrivenDevelopment is no magic cure for bugs.  In the face of combinatorial explosions of possibilities, TDD only ever tests a tiny few samples; it has none of the rigor of proof.  Tests should be encouraged and run, of course... but the strength of your endorsement here is misleading.  
**  The ConstQualifier's main purpose is in documenting that an object will not or shall not be changed by use of a particular procedure.  This is often far more useful to the programmer (esp. secondary users) than it is to the compiler.  You may argue that 'const' should be, instead, part of the documentation.  I counter: all parts of interface documentation ought to be compiler-enforced; 'const' is just a useful start.  


----
CategoryCpp