🚀 go-pugleaf

In <1992Aug20.215455.17279@microsoft.com> jimad@microsoft.com (Jim Adcock) writes:

>In article <1992Aug18.045605.14220@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
>|	To reiterate, all I would like is to guarantee that the *call*
>|	to a non-virtual member-function will succeed and that it's my
>|	responsibility to check for a non-nil 'this'.

>First, note that this would not come at "zero" cost.  As in the case of
>assigning to a reference, requiring "this" to be non-null allows compilers
>to avoid generating code to preserve nullness when adjusting pointers
>in the case of MI.  In the case of references, this issue has already
>been reviewed and decided upon: one is not allowed to have null references.

	I was under the impression that for MI, once a this pointer became
	zero it has to stay zero, so it constitutes a special-case now.
	Hence, why wouldn't be a zero-cost feature?

>Further, note that member functions can be called either on a pointer or
>on a reference.  If the language were to PERMIT calling member functions
>on a null pointer, such would not ALLOW *you* to test for null "this" inside
>you member functions, but rather would REQUIRE all of *us* to test for
>null "this" inside ALL *our* non-virtual member functions -- because a user
>of our class such as yourself could then legally call *our* member functions via
>a null pointer.  If such were the case then, the only sane remedy C++
>programmers would have would be to declare all their member functions virtual.
>Then *you* *still* could not legally call these members on a null pointer --
>but many member functions would now be needlessly slow and generate needlessly
>large code.

	I don't think that it would require everyone to test this for
	zero.  I had said that this would be usedful only if a majority
	of member-function calls were made via a pointer, i.e.,
	linked-list and perhaps other container classes that use linked
	lists for their implementation.

	Such a class would have as part of it's documentation: "This
	class is null-this safe" meaning it would do something sensible,
	or more likely nothing at all, for a null this pointer.  

	Other "concrete object" type classes, i.e., complex numbers,
	would have no need of being "null-this safe."

	It wasn't my intent to introduce the feature just so all
	programmers could forbid it by making everything virtual.

	If programmers elected not to check the this pointer, then the
	program, if a member is accessed via a null-this, would most
	likely crash or at least be undefined; this is _exactly_ the
	way language is defined now; hence, for programmers who ignore
	it, the (errant) behavior of their programs is unchanged.

	*****************************************************************
	Hence, adding my proposal changes nothing for those who ignore
	it.
	*****************************************************************

	Again, all I want is the *call* to succeed; after that, I'm on
	my own.

>I suggess instead that you use friend functions or static member functions 
>where you feel you must address null pointers implicitly.  Alternately, note
>that the users of your class may be the ones in the best position to perform
>the null pointer tests [explicitly].

	Perhaps [with regard to users checking null tests]; but I think
	that one of the _themes_ of programming in C++ is to eliminate
	tedium and errors introduced thereby: virtual functions
	eliminate switch statements missing a case; exception-handling
	will eliminate having to check the return value from new to see
	if it failed, etc.

	I see my (modest) proposal in the same light.

	Further comments?
-- 
	- Paul J. Lucas				University of Illinois	
	  AT&T Bell Laboratories		at Urbana-Champaign
	  Naperville, IL			pjl@cs.uiuc.edu