🚀 go-pugleaf

A couple of comments/questions on John Rose's technique described in
<4431@think.ARPA> for guaranteeing de-initialization of objects in C++
when longjmp is used:

1)  To use the example of class open_file, what if one writes

	{
		open_file f1("foo");
		open_file f2("bar");
		...
	}

and the block is exited normally; i.e., not by means of longjmp.  Does (should)
C++ guarantee that the destructors will be called in the opposite order that 
the constructors were called?  If not, the catch frame list might be corrupted.

2)  There is also a problem if one does
	
	open_file* f1 = new open_file("foo");

The catch frame constructor should probably check for this==0 before linking
the frame to the catch frame list.

3)  Please explain why spring() must be first in struct:

	class open_file {
		friend file_catch;
		class file_catch : catch {
==>			void spring() // depends on being 1st in struct:
				{ fclose(((open_file *)this)->fp); }
			} cb;
		FILE*	fp;

I think this is a very useful concept.  One could even define useful
classes whose functions are accomplished solely by
constructor/destructor functions; for example, a class CriticalRegion
might be defined with a constructor that did a WAIT on a specified
semaphore and a (guaranteed) destructor that did a SIGNAL on the same
semaphore.  Declaring a CriticalRegion object at the beginning of a
block would then assure that the semaphore was SIGNALled no matter how
the block were exited:

	{
		CriticalRegion foo(some_semaphore);
		...
	}

-- 
---
	Keith Gorlen
	Computer Systems Laboratory
	Division of Computer Research and Technology
	National Institutes of Health
	Bethesda, MD 20892
	phone:	(301) 496-5363
	uucp:	{decvax!}seismo!elsie!cecil!keith