billwolf@hubcap.clemson.edu (William Thomas Wolfe,2847,) (12/31/88)
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