Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ncar!ames!apple!apple.com!arn
From: arn@apple.com (Arn Schaeffer)
Newsgroups: comp.lang.c++
Subject: More const member function ramblings
Message-ID: <3102@internal.Apple.COM>
Date: 25 Jul 89 23:53:22 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 41

I recently posted a message discussing what the semantics of const member 
functions is.  As defined, const member functions make a statement about 
storage and say nothing about the "constness" of an object with respect to 
it not changing in a way perceptible to the outside.  The following 
example really demonstrate how great a difference these semantics are:

class TFoo {
  public:
    virtual void  ChangeMyStateInSignificantWay();
};

class TBar {
  public:
    virtual void  SomeConstantOperation() const;
    // More functions - some of which export information via calls to fFoo.
  private:
    TFoo* fFoo;
};

void TBar::SomeConstantOperation() const
{
  fFoo->ChangeMyStateInSignificantWay();
}

Now, if we have a const TBar object and call the member function, 
"SomeConstantOperation," the storage of the object hasn't changed but the 
external state of the object has changed (presumably, there are more 
functions which would reveal information about the TFoo part which has 
been changed in a significant way as a result of this "const" operation).  
Furthermore, even if we have an embedded object (that is, the private part 
of TBar would be TFoo fFoo), the language seems to allow the call.  These 
semantics seem consistent with the "storage" model but somewhat 
misleading.  Are the current semantics of const (and lack of support for a 
"stable object as viewed via the external interface" semantics) viewed as 
a problem by other people or am I fighting an uphill battle?

Arn Schaeffer
Apple Computer
arn@apple.com

The opinions expressed are not necessarily those of Apple Computer.