Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.lang.c++
Subject: Re: Null references
Message-ID: <70778@microsoft.UUCP>
Date: 19 Feb 91 18:50:31 GMT
References: <1991Feb13.224743.1123@lia>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 78

In article <1991Feb13.224743.1123@lia> jgro@lia.com (Jeremy Grodberg) writes:
|I've been looking through the ARM to try to find out how Null pointers and
|references work together, and I can find neither any guarantees nor any
|statments that the behaviour is undefined.  Here is a very simple example
|of what I want (it is of course too simple to be useful).
|
|#define NULL 0
|
|int* square(int& x)
|{
|   if (&x != NULL) 
|     x *= x;
|
|   return &x;
|}
|
|main()
|{
|  int* p = NULL;
|  int& death = *square(*p);  // I want a *guarantee* that this will not crash
|
|  death = 0; // Of course, this causes a run-time crash
|}
|
|
|In other words, I want a guarantee that pointers are not dereferenced
|when initializing references.   This is in fact the observed behavior of
|CFront 2.0.  It is useful in some circumstances when you want to 
|preserve object semantics with references, but occasionally have a null
|object reference.  For example, suppose I want to implement a look-up
|table, and my find() function needs to return an object.  It is much
|more efficient to return an object reference, but I would like to return
|NULL if I can't find the requested object.  I currently have no guarantee
|that this will work, and my only other solution is to return an object
|pointer.  This makes references less useful, and burdens the rest of my
|code with creating temporary pointers to hold the return results so I can
|check it against NULL before converting it to a reference.  There are other
|situations in which null references substantially clean up the code.
|
|Since we already have all sorts of special case treatment
|of null pointers, and since we are guaranteed that the address (&) of
|a reference is the same as the address of the object which it refers to,
|it doesn't seem like such an extra burden to allow the creation of 
|null references.
|
|If the ANSI comittee thinks this guarantee is too hard to make, and/or
|just isn't worth the effort, then I would like a statment to that effect
|added to the standard, so that we can all know this is non-portable,
|and so that people realize that null reference might be allowed by the
|compiler.  For example, if the initialization of "death" in my example
|is successful, some people will take that to mean that "death" refers
|to a valid object, and be totally confused when the simple assignement
|statement cause a crash.  The statement that null references have 
|undefined behaviour will help alert people to that situation.

I agree with your desire that C++ support null references.  I asked for
clarification on this issue on comp.std.c++ some time ago, and I think
the issue has been discussed by the ansification committee, and I think
the answer is that they decided *not* to explicitly support null references.
Perhaps someone on the committee can confirm or deny this?

The case *for* null references includes:

*that they are the equivalent to null pointers 
*they allow references to be used in many situations where pointers historically	were.
*compilers can't in practice afford to generate code to keep from allowing
	null references in most cases
*in a few obscure situations null reference WONT work correctly unless 
	compiler support is added.
*in those few situations if a null pointer is converted to a null reference
	extremely obscure bugs will result.

The case *against* null references includes:

*in a few obscure situations this will allow faster, smaller code to be
	generated.
*not allowing null references might allow more flexibility in porting C++
	to future "object-oriented" CPU architectures.