From -2131596651930176586
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,f9d03435d36a70ff
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1990-08-10 16:38:03 PST
Path: gmdzi!unido!mcsun!uunet!decwrl!ads.com!sparkyfs!mckenney
From: mckenney@sparkyfs.istc.sri.com (Paul Mckenney)
Newsgroups: comp.std.c++
Subject: Re: 'const' revisited
Keywords: const access restrictions
Message-ID: <32550@sparkyfs.istc.sri.com>
Date: 10 Aug 90 16:35:33 GMT
References: <26909@pasteur.Berkeley.EDU>
Reply-To: mckenney@perth.itstd.sri.com.UUCP (Paul E. McKenney)
Organization: SRI International, Menlo Park, CA 94025
Lines: 31
Posted: Fri Aug 10 17:35:33 1990

In article <26909@pasteur.Berkeley.EDU> twagner@madrone.berkeley.edu (Tim Wagner) writes:
> [....]
>One possible solution is to apply machine-independent semantics for the
>keyword volatile.  That is, the following chart will obtain:
>      | volatile | none
>-------------------------
>const |     A    |  B
>-------------------------
>none  |     C    |  D
>-------------------------
>A:  A name declared with these specifiers has a read-only access restriction
>    associated with it (i.e., the name is read-only), but the underlying
>    object is read/write.  Casts to B can occur implicitly; casts to
>    C or D must be explicit.

I disagree with this interpretation; the name declared might well refer
to a register that is updated by hardware but that is not to be touched by
at least part of the software.  For example, the register might be
part of a real-time clock, and writing to the register might have
the effect of setting the clock -- not an operation to be performed
lightly!

In this case, the compiler should prohibit modifying the object referred
to by the name, but must not assume that a copy of the object still has
the same value as the object itself (since the object is subject to change
by outside agents).

Therefore, I feel that casts from A to all of B, C, and D should be explicit.


					Thanx, Paul