dsouza@mcc.com [Desmond D'Souza] (11/28/89)
Summary: Why cannot a reference be changed ?
Firstly, I LIKE "reference" types. Besides function call/return
efficiency, I like true call by reference semantics, without having to
mess with pointers and de-referencing. I also like being able to share
references to the same object without treating the reference as a
pointer.
e.g. a CAR object contains a reference to an ENGINE object.
a REPAIR may share a reference to the same ENGINE.
I do not understand this restriction: [B.S. "The C++ Prog.Lang", p.56]
"A Reference always refers to the object it was initialized to denote"
If references are implemented by pointers, why should a reference not
be able to be associated with different objects at different times ?
If this was possible one could use references in a lot of other
places, and save pointers for things like pointer arithmetic.
e.g. Suppose at some point I need to change the engine in my car: I am
forced to resort to using pointers to an ENGINE (and possibly have to
modify code to conform to the change).
Or, suppose I simply cannot commit to an engine at the time the car is
constructed, and only do so at some later time.
Solutions:
1. Use pointers: the only current option
2. Permit references to change (i.e. define some operations
besides initialization, on "references" themselves) :
We would need to do the following to references:
1. check if they are currently associated with an object:
like a void pointer check
2. re-associate a reference: like a pointer assignment
3. possibly, sever an association: like assigning NULL to pointer
Problem: Cannot use "=" , since the assignment operator has
a pre-defined (or overloaded) meaning for the referred-to class.
Solution:
Since all reference types would need this, and existing operators
-- overloaded or not -- should operate on the referred-to object,
maybe use some existing keywords ?
MyClass& ref;
MyClass obj;
ref.void() ; // like: Check (ptr == 0)
ref.switch(obj) ; // like: pointer assignment (ptr = &obj)
ref.break() ; // like: NULL assignment (ptr = 0)
Maybe member functions should not be used, but you get the idea.
Of course, there may be some quite profound reason for the restriction which
I have missed completely.
Desmond.
Desmond D'Souza, MCC CAD Program | ARPA: dsouza@mcc.com | Phone: [512] 338-3324
Box 200195, Austin, TX 78720 | UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!dsouzasabbagh@acf5.NYU.EDU (sabbagh) (11/28/89)
>Summary: Why cannot a reference be changed? As I understand it, references were introduced to C++ as a "correction" to C. Its primary purpose is to minimize copying of objects onto the stack; this can be done with C using pointers, but this has the problem that the _caller_ must know to take the address, resulting in maintainability problems. > e.g. a CAR object contains a reference to an ENGINE object. > a REPAIR may share a reference to the same ENGINE. > ... > e.g. Suppose at some point I need to change the engine in my car: I am > forced to resort to using pointers to an ENGINE (and possibly have to > modify code to conform to the change). > > Or, suppose I simply cannot commit to an engine at the time the car is > constructed, and only do so at some later time. Not to start a flame war, but pointers _are_ the correct solution to this problem, from a semantic point of view. In the above CAR, REPAIR example, it is important to note that you are not only referring to an ENGINE, but your are also (indirectly) REPAIRing the CAR containing the ENGINE. In this sense, pointers and references are the same, and C++ supports extensive pointer semantics. Hadil G. Sabbagh E-mail: sabbagh@csd27.nyu.edu Voice: (212) 998-3285 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 186,282 miles per second -- it's not just a good idea, it's the law!
jimad@microsoft.UUCP (Jim Adcock) (11/29/89)
// At least present compilers don't strictly enforce this restriction --
// my 1.2 compatible version accepts the following. It would be nice to
// know what the real restrictions really are, and why. Presumably,
// eventually, it will be possible to make C++ compilers that
// generate more efficient code based on the knowledge that references
// "don't change." A reference is not the same thing as an automatically
// dereference pointer -- that just happens to be the way that cfront
// implements them. Anybody know what the "real rules" are in using
// references? Is the below legal, or just not yet enforced by compilers?
#include <stdio.h>
typedef char* strng;
strng v[] =
{
"hi mom",
"hi dad",
"hi bro",
"hi sis",
0
};
main()
{
strng* p = v;
while (*p != 0)
{
strng& str = *p;
printf("%s\n",str);
++p;
}
}horstman@sjsumcs.sjsu.edu (Cay Horstmann) (11/30/89)
I always thought there was a perfectly simple reason why one can't modify a reference. How would you do it? int& r = a; // i.e. really r is a pointer, initialized with &a int n = r; // i.e. really n = *r r = 5; // i.e. really *r =5 Every time you write r, it really means *r. Therefore, there is NO WAY to change the reference. Well, I suppose it would be logical to allow &r = b; // now r a reference to b? but it would be quite unintuitive. Cay
ark@alice.UUCP (Andrew Koenig) (12/01/89)
In article <1989Nov30.053552.6149@sjsumcs.sjsu.edu>, horstman@sjsumcs.sjsu.edu (Cay Horstmann) writes: > Well, I suppose it would be logical to allow > &r = b; // now r a reference to b? > but it would be quite unintuitive. It also wouldn't work. What if r is an object of a class with operator&() defined? -- --Andrew Koenig ark@europa.att.com