🚀 go-pugleaf

In <23512@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:

>Perhaps someone might like to try to construct an example of why
>it might actually be useful to allow this==0 in a member function.
>I've been away, so I've missed some messages, but so far the only
>justification I've seen is statement like `it seems like a good idea.'

>I find it hard to imagine why it would be useful.  A member function
>that never looks at `this' could just as well be made static;
>one that actually uses `this' had better not be called with this==0.
>Thus it appears that the only useful cases are:

>	1. a function that actually checks if this==0 and does different
>	   things depending on the result, or

>	2. a function that looks at this only if one of its arguments has
>	   a particular value.

>Both of these cases seem contrived to me, to the extent that I would
>expect to be able to accomplish an equivalent thing more elegantly by
>other means.

>Can someone actually come with a useful example?

	My original example is for classes whose objects are dealt with
	almost exclusively via pointer, e.g., canonical linked-list
	classes or other container classes that use linked-lists for
	their implementation.

	The example I gave was the member-function:

		void Link::DeleteAll() {
			for ( Link *p = this, *q; p; p = q ) {
				q = p->next;
				delete p;
			}
		}

	where the Link class is what you'd expect, i.e.:

		class Link {
			Link *prev, *next;
			// ...
		};
	
	The DeleteAll() member, if pass a nil pointer, would (should) do
	nothing because its this == 0 to start out.

	Also consider:

		Link* Link::Cut( int how_many = 1 ) {
			// "cut out" how_many links starting at this
			// and return a pointer to the new sub-list.
			// If how_many == 0, return 0
		}

		void Link::Delete( int how_many = 1 ) {
			Cut( how_many )->DeleteAll();
			// Note that if Cut() returns nil, it would be
			// if calls where this == 0 were guaranteed to
			// work.
		}
	
	There are also many other examples along similar lines where not
	having to check for this == 0 would be nice.  Clearly, these
	members can not be static.

	To reiterate (for Andrew's sake), I also think that one of the
	_themes_ in C++ is to lessen or eliminate tedium and errors
	introduced thereby, e.g., virtual functions eliminate missing
	cases in swith statements, exception-handling (when it gets
	here) to eliminate explicit checks for nil pointers returned by
	new() (among other things), etc.  I seem my (modest) proposal in
	the same light.

	Again, to reiterate (for Andrew's sake), I think it's a
	zero-cost feature; code that works now will continue to work,
	and programmers who ignore it will be unaffected, i.e., if they
	don't check 'this' their programs will exhibit undefined
	behavior (by trying to access members) and "undefined behavior"
	is what happens now anyway.

	If nothing else, I would at _least_ like those two seemingly
	contradictory paragraphs in the ARM explained, i.e., the ones
	that say:

		...calling a non-virtual member-function for something
		that is not an object should be expected to fail
		eventually... (or something along those lines)
	and:
		Naturally, this trick would work if the member were to
		check its this pointer before accessing any members...
	
	Does the latter sentence mean that it really _is_ ok to make the
	_call_ with a this == 0, i.e., do I already have what I want?

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