Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!sdd.hp.com!uakari.primate.wisc.edu!aplcen!aplcomm!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: >this< as a reference
Keywords: references C++ OO
Message-ID: <58470@microsoft.UUCP>
Date: 22 Oct 90 23:08:16 GMT
References: <2058@aber-cs.UUCP>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 103

In article <2058@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
|In article <58304@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
|
|  >Now that there is no need to assign to >this<, wouldn't it have
|  >been cleaner if >this< were a reference, and not a pointer ?
|  
|  I think so, but if one had made "this" a reference [in which case call
|  it "self"] then one should have changed other parts of the language to
|  return references too.  For example, in that case "new" should return
|  a reference rather than a pointer too.
|
|This looks very bizarre to me. Are you under the impression that references
|are kind of like pointers? I do not think so. I think they are very
|different. I guess that the new operator should continue to return pointers
|even if there are rerefences around.

References are kind of like pointers, in that in common use both allow a 
way to access and send messages to objects:

object.doSomething();  // verses:

object->doSomething();

The point I was trying make is that in a language that supports two ways of
sending messages, either one of the two techniques are central, or you duplicate
every feature of the language everywhere.  If you want to make the 
"reference" style of programming central, then "this" [self] is a "reference", 
and so are other common features of the language, such as return values of new. 
If you want to make the "pointer" style of programming central, then you leave
the language the way it is.

|C++ references are like Algol 68 constant references, i.e. aliases. Pointers
|are another way of doing aliases, but they have one level of indirection more
|than C++ references (they are references to references).

Agreed.  If C++ references are constant references, this leaves the 
possibility open for references that are not constant -- ie they are 
re-assignable.  If one had re-assignable references in C++, then one could
program using a syntax almost identical to most other OOPLs.

|  Not using references for everything has given C++ some indirect advantages,
|  though.  Most other OOPLs always access objects via reference, using 
|  reference semantics.
|
|Read "pointers" throughout... Of course C++ has the advantage that to define
|composite it can use contiguity and not just pointers. This is a *large*
|advantage, and makes it clear that things like derivation are only justified
|in the context of a pointer based OO language, which C++ is not.

Hm, I don't get this, you say that contiguity is a great advantage, but then
state [without justification] that derivation is only justified in the context
of a pointer based OO langauge, which C++ is not.  So you seem to be stating
that you think contiguity is good, but prohibits derivation?  Can you 
explain this position?

|  This hinders their ability to offer extended "primitive" classes such as
|  class complex or String classes.
|
|In no way I am aware of, frankly. Unless you are speaking of efficiency. But
|Smalltalk is a pointer based OO language and it does provide fine
|granularity (not "primitive" -- they are composite) classes, slowly.

Primitives need to be created on the stack or in globals.  Most OOPLs provide
for a very limited set of built-in primitives that follow value semantics,
and require all programmer created types be non-primitive classes that 
follow reference semantics, are created on the heap....  Conversely, C++
allows one to add to the set of built-in primitive types with addition 
types of "simple" objects that follow value semantics: complex, iostream,
iter classes, etc are some example of these extended primitive classes.
I do not define primitive as non-composite, but rather classes that are
relativily simple and follow value semantics, rather than reference semantics.

|  So, overall, I think the C++ approach has faired pretty well for the
|  language, even if the duality of pointer/reference semantics everywhere
|  leads to some confusion.
|
|No confusion at all for those who have studied Algol 68 or BLISS:
|
|	C++				Algol 68
|
|	const int c = 10;		INT c = 10;
|
|	int i := 100;			INT i := 100;
|	int &j = i;			REF INT j = i;
| ....

Experience with Algol may help one understand C++ references, but it in 
no way helps one remember which of the . or -> syntax one needs to use when
dealing with someone else's classes, nor whether a reference or a pointer is
expected as a parameter, or is returned from a routine, or ....:

    object = something->subpart()->doSomething(someParam);
    object = &(something->subpart()->doSomething(*someParam));
    object = *(something->subpart()->doSomething(&someParam));
    object = *(something.subpart()->doSomething(someParam));
    object = *(something.subpart->doSomething(*someParam));
    object = something.subpart.doSomething(&someParam));

Unfortunately, the number of reasonable conventions [including not using
*any* conventions] exist that a C++ programmer runs into a different set
of usage conventions for each and every different set of libraries used.
Thus some complain that C++ is not an object oriented language, but a set
of tools for programmers to build their own object-oriented language on top of.