From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=5.0 tests=BAYES_20,INVALID_DATE, MSGID_SHORT,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Xref: utzoo comp.lang.misc:1373 comp.lang.modula2:733 comp.lang.ada:1089 Path: utzoo!mnetor!uunet!husc6!bbn!rochester!crowl From: crowl@cs.rochester.edu (Lawrence Crowl) Newsgroups: comp.lang.misc,comp.lang.modula2,comp.lang.ada Subject: Re: From Modula to Oberon Message-ID: <8196@sol.ARPA> Date: 30 Mar 88 15:32:53 GMT References: <145@krafla.rhi.hi.is> <272@fang.ATT.COM> <429@zap.UUCP> Reply-To: crowl@cs.rochester.edu (Lawrence Crowl) Organization: U of Rochester, CS Dept, Rochester, NY List-Id: In article <429@zap.UUCP> fortin@zap.UUCP (Denis Fortin) writes: >... in a language that encourages information-hiding, a good garbage >collector is almost a must (in my opinion). ... Without garbage collection, >you have to have a free/dispose/unchecked_deallocation routine available for >all hermetic data types you export, ... [otherwise you limit subsequent >implementations] ... but then it becomes a real pain to write code that uses >the data type. C++ provides the notion of a *destructor*. Whenever you define a class (abstract data type), you may define a destructor. The destructor is *implicitly* called when the variable is deleted (e.g. at the end of the procedure for local variables). The implementation of the class may change from static allocation to dynamic allocation, without changing the client code, without leaking memory, and without explicit client control of deallocation. Garbage collection is one approach to reducing the storage management burden on programmers. It is not the only approach, nor is it always the best approach. -- Lawrence Crowl 716-275-9499 University of Rochester crowl@cs.rochester.edu Computer Science Department ...!{allegra,decvax,rutgers}!rochester!crowl Rochester, New York, 14627