Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!odi!benson
From: benson@odi.com (Benson I. Margulies)
Newsgroups: comp.lang.c++
Subject: Re: Help needed in c++
Message-ID: <1991Jun23.115933.28235@odi.com>
Date: 23 Jun 91 11:59:33 GMT
References: <3257@odin.cs.hw.ac.uk> <1991Jun19.141917.18345@auto-trol.com> <1991Jun22.162513.183@and.cs.liv.ac.uk>
Organization: Object Design, Inc.
Lines: 33
In-Reply-To: markr@and.cs.liv.ac.uk's message of 22 Jun 91 16:25:13 GMT

the const function declaration item serves two purposes. It declares
an characteristic of an Interface, and it enforces restrictions on its
contents.

Well, the referenced posting is an example of something that happens
fairly commonly in my experience -- a member function whose interface
is const actually needs to modify its private internal state.

You can argue till the cows come home as to whether this is
"legitimate." The argument in favor is that the private contents of an
object are no one's business but the object's, and if it chooses to
modify them in a "const" method that's its business. The anti-
argument is that const on a member function is a statement about
storage integrity -- a const object, in this theory, can be stored in
a ROM.

In the real world, do the following. Decide which of the positions to
believe. If you believe that pro is appropriate for your application,
you write

    ((myclass *)this)->state = whatever;

to cast away the const.

If you believe that anti is the ticket, then you have to maintain,
for example, a hash table from this pointers to non-const state
containers, and modify those.

    myclass::state_hash[this]->address = whatever;


-- 
Benson I. Margulies