Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!husc6!mailrus!umich!itivax!scs
From: scs@itivax.UUCP (Steve C. Simmons)
Newsgroups: comp.lang.c++
Subject: Re: Exception Handling
Summary: Meta-bojects and garbage collection
Keywords: garbage collection scope object scope
Message-ID: <303@itivax.UUCP>
Date: 11 Oct 88 15:07:13 GMT
Article-I.D.: itivax.303
References: <294@itivax.UUCP> <797@nih-csl.UUCP> <298@itivax.UUCP> <4370@polya.Stanford.EDU> <301@itivax.UUCP> <4383@polya.Stanford.EDU>
Reply-To: scs@itivax.UUCP (Steve C. Simmons)
Organization: Industrial Technology Institute, Ann Arbor
Lines: 42

In article <4383@polya.Stanford.EDU> shap@polya.Stanford.EDU (Jonathan S. Shapiro) writes:
[[a nice explaination to my question about why destructor ordering
  is important in garbage collection scope/exception handling]]
>The reason ordering is important is that there is a metasemantics to
>object creation order. Consider a linked list.  Destroying the head
>might be implemented to destroy the rest, but I might be referring to
>that object someplace else.
>....
>Now the metasemantics of the ordering is not readily expressible in
>the language.  How should this problem be addressed?

Perhaps our problem is that we are failing to properly treat collections
of objects.  If an object is contained within a larger object, this is
something we need to consider when defining the constructor/destructor
for both of the objects.  Taking an example:

We have a class string which contains a reference count.  When refcount
is zero, it calls its destructor.  We have a class stringlist which is
a linked list of strings.  Should the use of a string in the linked list
comprise a reference to it?  If you say yes, then as long as the string
is on the list it will never be released.  If you say no, we have to deal
with the case of a list containing a destroyed object.

In either case, it's something we *should* be accounting for in
designing the list object.  Should the list object should be smart
about the objects it contains, and be able to remove items from the
list when the list is the only referent?  Clumsy, but maybe appropriate
for some objects.  More general is a list object that notices when
something it references has been deallocated and cleans up the list.
But just how do we detect that in a reliable fashion?

Hmm.  Now we've got an example where the cleanup problems are
independant of exception processing.  Could we be so bold to say
that there are no cleanup problems that could not arise independant
of exception processing?  I dunno.

This is a very slipperly slope we're talking about.  Pretty much everything
I can think of seems to seriously bend the rules of data hiding.  Sigh.
-- 
Steve Simmons		...!umix!itivax!scs
Industrial Technology Institute, Ann Arbor, MI.
"You can't get here from here."