Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Keywords: const access restrictions
Message-ID: <56586@microsoft.UUCP>
Date: 15 Aug 90 17:08:18 GMT
References: <26909@pasteur.Berkeley.EDU> <56514@microsoft.UUCP> <1990Aug14.125734.28015@cbnewsm.att.com>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Distribution: usa
Organization: Microsoft Corp., Redmond WA
Lines: 28

In article <1990Aug14.125734.28015@cbnewsm.att.com> gregk@cbnewsm.att.com (gregory.p.kochanski) writes:
>AARGH!
>One might as well use const(1) const(2) const(3) ... rather than
>trying to express these things in terms of non-intuitive ordering
>of const and volatile.  Unless the syntax is memorable, it will not be
>used or used correctly.   There is such a thing as being excessively
>parsimonius with keywords.

Yes.  You highlight well the concerns I had in proposing the ordering
approach to overloading.

What you don't do it make a counterproposal as to how to resolve the 
present problems with const.  Any suggestions?  Four different approaches
might be:

1) Const means const.  Period.  No exceptions.

2) Volatile const and/or const volatile mean the same thing:  A read-only
object that can change of its accord.  Const by itself means const without
exception.  Volatile const is then an object that cannot be
enregistered in whole nor part.

3) Volatile const verses const volatile distinction.

4) Leave things the way they are now -- a muddle where people cast away from
const, leading either to compilers that can't optimize on const, or compilers
that do optimize on const, with "quasi-const" routines that break the
caller's code.