NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/cplus/12661

Text File | 1992-08-20 | 3.3 KB | 67 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: Garbage Collection for C++
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]> <[e-mail]>     <[e-mail]>     <[e-mail]> <[e-mail]>
Date: Thu, 20 Aug 1992 18:02:47 GMT
Lines: 55

[e-mail] (Thomas M. Breuel) writes about whether GC should
call destructors:

>I think the answer is simpler than that. Delete should continue to
>work as it does (including returning memory to the system).
>
>In addition to that, there may be facilities to allow the programmer
>to specify finalization of heap objects that are about to be collected
>but have not been "deleted". Such a facility would not require any
>language changes; something like "gc_set_finalization_hook(void*,void
>(*f)(void*))" might do the trick. Some people may prefer to use such a
>facility simply to detect memory leaks in existing programs, while
>others might want to use it, for example, to release external
>resources.

It seems quite clear (to me :-) that objects must be destroyed before
their storage can be reclaimed. The idea that we should have a separate
finalization function that is called instead of the destructor seems to
be a step backwards. I cannot imagine any situation in which the
finalization function would do anything different from the destructor.

Exactly the same difficulties with quasi-non-deterministic execution
order apply to a finalization function called during gc as apply to the
destructor being called during gc.
Unspecified order of execution of destructors for GC'ed objects does
not appear to be much of a problem to me; we already have unspecified
order of execution for arguments to a function call, etc., and
destructors generally don't have side-effects apart from resource
de-allocation, so they are generally don't interact with each other.

The only advantage of having a finalization function instead of calling
the destructor seems to be that for optimization purposes, it is may be
desireable to optimize the common case when the destructor is empty
(does nothing). However this should not be too difficult for any but
the most naive implementations.

Furthermore, for MY code, the finalization function version would
result in LESS efficient code, because if the destructor version wasn't
in the language, then I would have to simulate it manually, by having
the finalization function explicitly call the destructor. This is very
messy as well as being less efficient. Having a finalization function
which I have to remember to install every time I call gc_new is both
tedious and error-prone.

    void f (iostream &);
    f(*gc_new fstream(...));
    // Oops! Forgot to write and install a finalization function
    // for the fstream allocated with gc_new.
    // The file may never get closed.

--
Fergus Henderson             [e-mail]
This .signature VIRUS is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!