From: billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Subject: Re: Life under implicit destruction
Date: 30 Dec 88 19:55:02 GMT [thread overview]
Message-ID: <3998@hubcap.UUCP> (raw)
In-Reply-To: 3996@hubcap.UUCP
From article <3996@hubcap.UUCP>, by wtwolfe@hubcap.UUCP (Bill Wolfe):
> From article <4200@enea.se>, by sommar@enea.se (Erland Sommarskog):
>> 1) You have several times stated that the callers of your ADTs
>> are responsible for that their destroy procedures are called.
>> So it's not only to write them. You must remember to call them
>> too. And when you forget, it takes time find out where.
Allow me to summarize Life Under Implicit Destruction, with
particular regard to programmer's responsibilities.
1) The responsibility for managing storage falls almost
completely upon ADT designers. They must write all
code having to do with allocating and deallocating
(and reusing old) storage associated with their ADT.
2) Users of the ADTs (application programmers) have only two
reasons for manually invoking DESTROY procedures:
a) Space is so tight that storage for every object must
be reclaimed the moment it is no longer useful.
b) To communicate to the maintainer and to the compiler
that a given variable is "dead".
3) Barring either of the two situations above, application programmers
will be concerned with space only in that they must create the
variables that they use, which is one of the effects of declaring
a variable (LRM 3.2.1 (7)). Currently, they are already accustomed
to declaring/creating their variables, so no additional work there.
To summarize, given the integration of ADT destruction routines into
block exit, application programmers will have NO (count 'em, none)
additional responsibilities, provided that they use ADTs rather than
trying to play with pointers themselves.
There are a few situations, such as construction of abstract syntax
trees in a compiler, in which application programmers really cannot
depend on ADTs to isolate them from data structure management. In
such cases, it may be best to borrow an ADT designer (a person who
is very much accustomed to space management) and have that person
desk-check and debug the final code with regard to space management;
perhaps the application programmers did OK by themselves, and I would
certainly hope that they did, but judging from the howls of protest
concerning how difficult it is to manage storage, I now tend to doubt
that the average applications programmer without ADT design experience
is capable of handling storage management in a professional manner.
(I hope I'm wrong; if anyone thinks storage management should be
within the intellectual capability of the average applications
programmer to handle, please speak up!)
The ADT designers have the reponsibility of managing storage, but
since they must satisfy the real-time programmers, they have this
responsibility already.
Since GC is worthless to an ADT designer, and application programmers
won't generally be doing things that would require GC anyway (and
I've outlined the contingency plan for when they do), there is
simply no need for garbage collection. It gives us only a permanent,
run-time cost, and no useful benefit, especially since it must waste
most of its time looking at storage which is being managed ALREADY
by the combination of scope management rules and ADT designers.
Bill Wolfe
wtwolfe@hubcap.clemson.edu
prev parent reply other threads:[~1988-12-30 19:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
1988-12-28 19:20 Garbage Collection Erland Sommarskog
1988-12-30 0:52 ` Bill Wolfe
1988-12-30 19:55 ` William Thomas Wolfe,2847, [this message]
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox