Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!ukc!edcastle!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.std.c++ Subject: Re: 'const' revisited Message-ID: Date: 17 Aug 90 16:07:37 GMT References: <26909@pasteur.Berkeley.EDU> <56514@microsoft.UUCP> <1990Aug14.224806.21375@brutus.cs.uiuc.edu> <9779@goofy.Apple.COM> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 32 In-reply-to: DEREK@AppleLink.apple.com's message of 15 Aug 90 21:28:31 GMT On 15 Aug 90 21:28:31 GMT, DEREK@AppleLink.apple.com (Derek White) said: DEREK> In fact, the recent examples that have shown a need for DEREK> "partially const" objects have fallen in the same catagory: I DEREK> think they can be solved by seperating the constant and variable DEREK> portions of an object into constant and varying fields or DEREK> classes. Excellent point. Moreover 'const' in C++ already has the right definition; thank Stroustrup for not having botched it like in Ansi C. i would hate that any debate on 'const' opened the way for the usual call to greater Ansi C conformity. Fortunately C++ is quite a different language. DEREK> Although it may be expedient to make a statement that an object DEREK> is const when it really isn't, I think in the long run honesty is DEREK> the best policy. I suggest a hard line approach: const is DEREK> constant. Again, we go back to my usual and tired observation; what we wnat to achieve is reuse of interface, proof and implementation, and overloading keywords can only go so far to this end (see how strained is the syntax for the = 0 virtual function case). C++ should provide mechanisms towards this, and mostly implementation oriented. 'const' as such is a statement on the implementation of an object, not on its interface or semantics. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk