From -4348230773988214074
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: f78e5,fc1538f2aa3fc9f8
X-Google-Attributes: gidf78e5,public
X-Google-ArrivalTime: 1993-01-08 16:35:03 PST
Newsgroups: comp.std.c++
Path: sparky!uunet!stanford.edu!lucid.com!lucid.com!jss
From: jss@lucid.com (Jerry Schwarz)
Subject: Re: Type System
Message-ID: <1993Jan9.001948.28388@lucid.com>
Sender: usenet@lucid.com
Reply-To: jss@lucid.com (Jerry Schwarz)
Organization: Lucid, Inc.
References: <1993Jan1.172044.9659@ucc.su.OZ.AU> <1993Jan4.194318.5340@lucid.com> <C0Iy9o.9x@frumious.uucp>
Date: Sat, 9 Jan 93 00:19:48 GMT
Lines: 33

In article <C0Iy9o.9x@frumious.uucp>, pat@frumious.uucp (Patrick Smith) writes:
|> jss@lucid.com (Jerry Schwarz) writes:
|> |The way I understand it, when an object is created (constructed)
|> |it can be "marked" as mutable or immutable. ("Marked" in quotes
|> |because no runtime marking is implied).  This mark cannot be
|> |changed.  The type system is designed so that (barring the
|> |use of unsafe casts) the following rule is assured.
|> |
|> |	If an lvalue has non-const type,
|> |	then it refers to a mutable object.
|> 
|> There is another loophole. :-(
|> But it's (I hope) an unusual type of situation. :-)
|> 
|>    struct A { A(); /*...*/ };
|>    A* pa;
|>    A::A { pa = this; }
|> 
|>    void f() {
|>       const A a;
|>       // Now pa has non-const type but points to an immutable object.
|>    }

You're right.  I knew about that loophole, but forgot about it when
I posted my original item.  If anyone has ideas for a clean way
to close this loophole, I'd be interested to hear them.  

The problem is that the object is only "marked" immutable when the
constructor returns.  The constructor itself is supposed to be free
to modify the object in any way it chooses.

  -- Jerry Schwarz