Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!apple.com!arn From: arn@apple.com (Arn Schaeffer) Newsgroups: comp.lang.c++ Subject: Const member function semantics Message-ID: <2943@internal.Apple.COM> Date: 20 Jul 89 21:39:08 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 34 I think the addition of const member functions is a powerful and necessary addition to the language; however, the semantics of a const member function declaration is essentially a statement about storage. That is, a const member function will not cause the actual bits in the object to change. For a simple non-virtual "getter," a const member function is an easy statement to make. Unfortunately, providing virtual const member functions is a bit tricky. It forces the class designer to make an implementation decision for all subclasses. Sometimes this is necessary because you need (or want) to make a statement about storage. Sometimes, you just want to make a statement that the object hasn't changed in any way that is perceptible through the interface. For example, I might have a member function that returns some information and caches the result in the object. Obviously, this can't be a const member function using the current definition of const, yet there is an important statement that the class designer would like to make (this object does not change in any way perceptible through the interface) that cannot be made. I understand the motivation about making const a statement about storage. I also think that it is tremendously valuable for non-virtual "getters." There are many general classes that I have developed which I am reluctant to make such a strong statement about storage (I don't want to tie the hands of subclasses) yet I'd be very willing to make an important statement that no perceptible change has occured to the object. Is it (will it be) possible for me to make the statement I'd like to make? In my work it seems that most of the time I don't want to make the statement about storage just about interface. The opinions expressed are not necessarily those of Apple Computer. Arnold Schaeffer Apple Computer, Inc. arn@apple.com