comp.lang.ada
 help / color / mirror / Atom feed
From: "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM>
Subject: Re: Garbage collection (was a spinoff of a spinoff of a GA
Date: 1996/10/21
Date: 1996-10-21T00:00:00+00:00	[thread overview]
Message-ID: <9610211427.AA06636@most> (raw)


It looks like Jon Anthony attempted to answer my question
in a post that never got to me.  And if you were to believe Alta Vista
you'd think neither Jon nor I ever posted on the subject!

But I DID see Jon's
> Second, none of this [finalization] stuff covers all the cases.  ....
> doesn't.  And, even if it were to work for the particulars of a
> specific application, you still have to go and roll your own stuff and
> make sure it is all correct and whatnot.  None of this is particularly
> incomprehensible.

Let me put my question another way:

What are the pros and cons of the following three choices?

Choice One (in the spec):
  Declare a data type.  Put a comment on it saying
  -- Make sure you put calls to the cleanup routines in in every place
  -- where an object of this type might leave scope.  Make sure you
  -- put an exception handler in every routine that declares one of these,
  -- or else ensure that no exception can occur.  And better guarantee that
  -- exceptions cannot occur in declarative regions.

Choice Two (in the spec):
  -- If you intend to use this data type, you had better ensure that your
  -- compiler has a good garbage collector, or get an add-on that can
  -- work with your compiler's allocation methods.

Choice Three (in the BODY):

   procedure Finalization (...) is
   -- this will ensure that cleanup cannot be forgotten.

What are the cases Finalization doesn't cover?  (Other than those the
programmer DECIDED not to apply it to.)

And what is so hard about "roll your own"?  After all this argument about
how and why this and that type of collector can bite you on the behind,
how can anyone complain that

   begin
     Free (Param);
   end Finalization;

is so difficult.  Sure, the compiler might fail to call it, but we have
better ways of dealing with naughty compilers than adding on outside tools
of arguable value.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------




             reply	other threads:[~1996-10-21  0:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-10-21  0:00 W. Wesley Groleau (Wes) [this message]
1996-10-22  0:00 ` Garbage collection (was a spinoff of a spinoff of a GA Jon S Anthony
1996-10-25  0:00   ` Jon S Anthony
1996-10-27  0:00     ` Garbage collection (was a spinoff of a spinoff of a GA diatribe) Robert Dewar
1996-10-25  0:00   ` Garbage collection (was a spinoff of a spinoff of a GA Robert I. Eachus
1996-10-24  0:00     ` Garbage collection (was a spinoff of a spinoff of a GA diatribe) Hans-Juergen Boehm
1996-10-25  0:00       ` Robert A Duff
1996-10-25  0:00         ` Hans-Juergen Boehm
1996-10-25  0:00     ` Brian R. Hanson
1996-10-30  0:00   ` Jon S Anthony
1996-10-30  0:00     ` Robert Dewar
1996-10-31  0:00   ` Jon S Anthony
  -- strict thread matches above, loose matches on Subject: below --
1996-10-17  0:00 Garbage collection (was a spinoff of a spinoff of a GA W. Wesley Groleau (Wes)
1996-10-20  0:00 ` Robert A Duff
1996-10-21  0:00   ` Michael F Brenner
1996-10-21  0:00     ` Larry Kilgallen
1996-10-21  0:00     ` Robert A Duff
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox