Thread View: comp.std.c++
4 messages
4 total messages
Started by John MAX Skaller
Fri, 01 Jan 1993 17:20
Type System
Author: John MAX Skaller
Date: Fri, 01 Jan 1993 17:20
Date: Fri, 01 Jan 1993 17:20
62 lines
2111 bytes
2111 bytes
Further to a previous post describing modifications to the type
system, I want to try to explain the underlying concept with some
further examples.
The basic idea is that 'int' and 'T' are object types,
whereas 'int&' or 'const int&' are not object types.
I would say they are 'accessors' to an object of type 'int'.
All identifiers (and expressions) are accessors.
Consider:
int x;
int& y=x;
const int& z=x;
In use, one cannot distinguish 'x' and 'y'. It is absurd IMHO
to pretend that 'x' is of type 'int' whereas 'y' is of type 'int&'.
Instead, one says that 'x' and 'y' and indeed 'z' refer to,
or access, an object of type int.
The 'access' method of both 'x' and 'y' is reference to int,
i.e. they are both 'int&'. 'z' is also a reference to an
int, but it has a restriction imposed preventing the call
of non-const functions.
Consequences: of this and the previous post:
consider a template function:
template<class T> f(T){ ... }
what function is generated by the calls
f(3);
f(x);
f(y);
f(z);
??
My system is simple: in all cases
f(int);
is used. If you wanted to create
f(int&);
you should have defined
template<class T> f(T&) { ...}
(in which case the calls f(3), f(z) are illegal)
The reason is trivial: <class T> stands for a class (or pointer)
type, ie an object type, and int& is not a type, but a reference
to an object of the type int.
--
;----------------------------------------------------------------------
JOHN (MAX) SKALLER, maxtal@extro.ucc.su.oz.au
Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------
Re: Type System
Author: Jerry Schwarz
Date: Mon, 04 Jan 1993 19:43
Date: Mon, 04 Jan 1993 19:43
34 lines
1929 bytes
1929 bytes
In article <1993Jan1.172044.9659@ucc.su.OZ.AU>, maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
|> Further to a previous post describing modifications to the type
|> system, I want to try to explain the underlying concept with some
|> further examples.
|>
|> The basic idea is that 'int' and 'T' are object types,
|> whereas 'int&' or 'const int&' are not object types.
|> I would say they are 'accessors' to an object of type 'int'.
The semantics of "const" in types is confused because it is also
unsed with a different meaning in the English descriptions of
C++. For several years I have been using "immutable" for this
sense of "const". That adjective hasn't yet caught on but,
I live in hope.
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.
Thus |int&| and |const int&| differ precisely because they
refer to objects rather than values. The values that these
objects can hold are the same, but the information we have
about the setting of the mutability flag is different.
Discussions of "const" in the type system become slippery because
when talking about values mutability is irrelevant and so "int"
and "const int" are in some sense the same.
-- Jerry Schwarz
Re: Type System
Author: Patrick Smith
Date: Fri, 08 Jan 1993 07:32
Date: Fri, 08 Jan 1993 07:32
26 lines
1212 bytes
1212 bytes
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.
}
--
Patrick Smith
uunet.ca!frumious!pat
pat%frumious.uucp@uunet.ca
Re: Type System
Author: Jerry Schwarz
Date: Sat, 09 Jan 1993 00:19
Date: Sat, 09 Jan 1993 00:19
32 lines
1682 bytes
1682 bytes
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
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads