Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!wuarchive!brutus.cs.uiuc.edu!nelson
From: nelson@melodian.cs.uiuc.edu (Taed Nelson)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Message-ID: <1990Aug14.224806.21375@brutus.cs.uiuc.edu>
Date: 14 Aug 90 22:48:06 GMT
References: <26909@pasteur.Berkeley.EDU> <56514@microsoft.UUCP> <CIMSHOP!DAVIDM.90Aug14141916@uunet.UU.NET>
Sender: news@brutus.cs.uiuc.edu
Reply-To: nelson@melodian.cs.uiuc.edu (Taed Nelson)
Organization: Picasso Group, University of Illinois at Urbana-Champaign
Lines: 40

In article <56514@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
> 
>    A) volatile const.  An object that appears const to the outside world that
>    may be changed internally.  An example might be an object that caches
>    certain values for faster access in the future.
> 
>    E) const volatile.  Read-only permissions to an object that may be
changing
>    of its own accord.  A example might be a clock register to which write
>    permissions need to be denied, because people shouldn't be allowed to
>    change the time.  Compilers can't optimize.


Our project has often felt the need for a "mutable" object class, which would
  be essentially equivalent to the "volatile const" above.  I also see the
  great need for the second.

Personally, I do not think that a const --> non-const class should be allowed
  (or at least highly discouraged) for the same reason that you cannot cast
  from a register to a static storage.  But that's all been discussed.

The example where we really felt the need for something between non-const
  and const (and that being constant to the user but the object may change
  its internal state) is for objects which have a "current placeholder" type
  of field.

For example, we have a Dictionary class which is kept current by the system,
  not the user / user program.  Whenever the user wants to use the dictionary,
  we give them a constant reference to it.  This allows them to extract entries
  (which return constant references as well) since that is a const
member function.
  Sometimes, though, the user will want to iterate over the entire dictionary.
  For that reason, we provide them with various First() and Next() functions.
  Unfortunately, the "current entry" which is needed for the Next() needs to
  be changed, thus violating the "constness" of the object.

We solved this problem by providing an "iterator" class which the user uses to
  provide the Next() functions (the iterator does the storing of the state
  information), but I don't think it very clean.  Especially since it requires
  another class...