[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
name for SEFTable
- To: <michael>
- Subject: name for SEFTable
- From: Mark S. Miller <mark>
- Date: Fri, 27 Oct 89 20:13:46 PDT
- Cc: <tribble>, <xtech>
- In-reply-to: <Michael>,12 PDT <8910262105.AA03066@xanadu>
Date: Thu, 26 Oct 89 14:05:12 PDT
From: michael (Michael McClary)
> From tribble Wed Oct 25 17:36:58 1989
>
> note that C++ uses 'const' incorrectly. You can have a 'const'
> pointer to an object that change state because another object has a
> non-const pointer. That's why immutability is different from 'const'.
> An immutable object can't have its state changed at all.
I agree that that's what it does, but I don't agree that it's
incorrect. "const" applies exactly to what it is applied to.
A "const" pointer is a pointer that may not be changed, which
says nothing about the object it designates. You would point
to a const object with a const pointer by saying:
const ConstType * doubleConstP;
while
ConstType * constTypeP;
would be a variable pointer to a const object, and so on.
I think the interesting case is:
Baz *const p;
This means that the holder of the pointer cannot modify the object
being pointed at if he accesses it through the pointer. I.e.,
p->foo();
is only allowed if foo() is a const member function of Baz. If he
also has an unconstrained pointer to the same object, he can modify it
through that path, and see the effect via messages on p. I actually
think that this is the right semantics for the construct. I just
think that "const" may not be a very good name for it.