From -87652281990295188 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,71f3c75b3c6b17cf,start X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1990-08-15 23:32:38 PST Path: gmdzi!unido!mcsun!uunet!decwrl!apple!AppleLink.apple.com!DEREK From: DEREK@AppleLink.apple.com (Derek White) Newsgroups: comp.std.c++ Subject: Re: 'const' revisited Message-ID: <9779@goofy.Apple.COM> Date: 15 Aug 90 21:28:31 GMT Sender: usenet@Apple.COM Organization: Apple Computer, Inc. Lines: 39 Posted: Wed Aug 15 22:28:31 1990 References:<26909@pasteur.Berkeley.EDU> <56514@microsoft.UUCP> <1990Aug14.224806.21375@brutus.cs.uiuc.edu> In article <1990Aug14.224806.21375@brutus.cs.uiuc.edu> nelson@melodian.cs.uiuc.edu (Taed Nelson) writes: > 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... I think the iterator solution is very clean. Seperate iterator classes allow multiple iterations over the same collection. They also neatly divide the job of iterating, and as you have shown, they pull out the variable part of a constant object. In fact, the recent examples that have shown a need for "partially const" objects have fallen in the same catagory: I think they can be solved by seperating the constant and variable portions of an object into constant and varying fields or classes. Although it may be expedient to make a statement that an object is const when it really isn't, I think in the long run honesty is the best policy. I suggest a hard line approach: const is constant. Derek White AppleLink: DEREK - Standard Discliamer -