Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!think!ames!pasteur!ucbvax!decwrl!labrea!polya!shap
From: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Newsgroups: comp.lang.c++
Subject: Re: Overloading operator new()
Message-ID: <4370@polya.Stanford.EDU>
Date: 9 Oct 88 21:47:44 GMT
References: <5949@june.cs.washington.edu> <294@itivax.UUCP> <797@nih-csl.UUCP> <298@itivax.UUCP>
Reply-To: shap@polya.Stanford.EDU (Jonathan S. Shapiro)
Organization: Stanford University
Lines: 57

In article <298@itivax.UUCP> scs@itivax.UUCP (Steve C. Simmons) writes:
>In article <797@nih-csl.UUCP> keith@nih-csl.UUCP (keith gorlen) writes:
>-In article <294@itivax.UUCP>, scs@itivax.UUCP (Steve C. Simmons) writes:
>-
>-I don't see what operator new() has to do with exception handling in C++.
>-The main problem with trying to do exception handling in C++ is that there
>-doesn't seem to be a good way to get the destructors called for auto
>-objects that go out of scope when an exception is raised.  operator new()
>-is only used when allocating objects on the free store with new, not when
>-they are auto.  Could you please explain?
>
>Exactly correct.  To use this solution, one has to either (a) use only
>static objects or those explicitly created with new(), or (b) overload
>the creator/destructor functions to use your garbage-collectable new().
>Or a combination of the two.  It's not a real elegant solution, but it'd
>probably work.

There is at least one way to do exception handling in the current
scheme of things.  It goes like this:

Exception handlers define a scope. Thus, we logically think about
instantiating the "catch" for the exception handling (in LISP terms)
and that the catch goes out of scope at some time in the future.
Within the scope of the "catch", the exception mechanism is active.

Think of the heap as a temporally scoped object, where the
instantiation of a "catch" scope logically partitions the heap into
stuff older than that catch and stuff newer than that catch.

Now overload all instances of New() within that scope so that the
run-time system maintains, along with the scope information, a spare
pointer to every object allocated with New() within that scope, along
with a pointer to the destructor function.  Thus, associated with each
heap scope we have a list of objects and their destructors.

When an object is destroyed, it's pointer pair is removed from the
list by the global delete() operator.

Now, when an error is raised or a "throw" is executed, we locate the
scope that is thrown to and destroy all of the stack-instantiated
objects. We then destroy dynamically allocated things in the clobbered
scopes in an undefined order.

There is [at least] one problem with this, which is that it is
possible to call a dynamic delete() on an object that has already been
deleted() by the recovery mechanism. This should be considered not to
be an error within the context of the recovery. The heap-scope oblist
can be used to verify these cases.

Now I know that there are lots and lots of problems here.  I also know
that I don't know a lot about exception handling.  Can someone give me
a non-flaming list of problems with this idea so that I can think on it
further?  The big problem I see is that there is no good ordering
constraint on the destructions.


Jon