arn@apple.com (Arn Schaeffer) (07/26/89)
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.