TITLE: What is the big fuss about const

PROBLEM: impellus@cs.ucsd.edu (Tom Impelluso)

Can anyone send me, reference to me, or point me in the direction of
some material which will explain this big fuss about const?


RESPONSE: rmartin@rcmcon.com (Robert Martin), 13 Jun 93

const?  Hmmm, yet it is time, grasshopper, for you to begin the long
through the myserious nature of const.

The idea behind const is simple.  When you declare something const,
the compiler wont let you change that thing.  

   const int i=5;
   i=6; // compiler says nosireee.

Just this is pretty useful.  It lets you declare constants that have
types and locations in memory, as opposed to #defines.  Also, the
compiler reserves the right to place such constants in the code
segment where they can be burned into ROM if necessary.  Finally, such
constants can be used in array declarations.

    const int maxSize=100;
    char buf[maxSize];

However, this path is frought with oddities that are best not covered
here.  Suffice it to say that extensive use of the above idiom will
lead you to some minor dissapointments.  Not that you should not try;
but expect complications down the road.

Many times we would like to pass an object to a function.

	void f(myobject o);

But myobject might be pretty big, and we don't want to copy it.  So
we could pass in a reference:

	void f(myobject& o);

But this allows f to change the passed in object.  We don't want that
either.  We don't know who is going to be writing 'f', and we don't
want to give that person license to change the argument.  So we make
the argument const.

	void f(const myobject& o);

This is now fast and safe.

Well, at least that's the ideal.  In reality 'f' will probably want to
call some member functions of 'o'.  However since o is not const, 'f'
can only call the member functions of 'o' that have been declared
const.

This is going to force you to declare those member function of
myobject that 'f' calls const.  While you are at it, you'd better
declare all the member function of myobject which don't change
myobject, const.

Hmmm.  But some of these functions pass myobject references to member
functions of other classes.  They say something like this:

	g->someFunc(this);

But now 'this' is const, so someFunc better be declared to take a
'const' pointer.  So you better go find someFunc and all the other
functions that are called this way and make them take const pointers.

But now those functions can only call const member functions..........


And on and on it goes.

---------------------------------------------------------------

Within a program which has never used const, the first const is like a
cancer.  It grows and spreads, creating compiler error after compiler
error, until the whole program is properly consted, or until you give
up and rip all the consts out again.

It is very difficult to start using const in a program which has not
used them.  It is much easier to start using const right away!.

Now, having said all this, I presume you may be somewhat discouraged.
But, there is great reward in using const properly.  Once you get the
hang of where to put the consts and when to use them, they give you a
very nice firewall, protecting you from bad assumptions made by you or
others.  They allow you to communicate your decisions better.

Also, there is a reason for the cancerous spread of const that I
described.  All those consts should really have been there.  Having
them there is a much more accurate description of the interfaces of
those classes.  

The whole thing began when I decided it was necessary to protect one
reference argument of one function.  From that point the consts spread
through many functions and many classes.  All of these consts were
necessary to support that initial decision.  So they are neither bad
nor useless.

Get in the habit of using const when appropriate, the habit will pay
you back.