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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,13d6cd0af0d0d769 X-Google-Attributes: gid103376,public From: hbaker@netcom.com (Henry Baker) Subject: Re: Does memory leak? Date: 1995/03/26 Message-ID: #1/1 X-Deja-AN: 100540721 sender: hbaker@netcom18.netcom.com references: <3kopao$ekg@nef.ens.fr> <1995Mar24.123006.9471@eisner> organization: nil newsgroups: comp.lang.ada Date: 1995-03-26T00:00:00+00:00 List-Id: In article <1995Mar24.123006.9471@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) wrote: > In article , hbaker@netcom.com (Henry Baker) writes: > > > Most serious Ada compilers try pretty hard not to leak from internal leaks. > > However, objects that you allocate yourself with 'new' are considered your > > problem. Huge amounts of network, conference and newsletter bandwidth have been > > wasted on trying to get around the fact that Ada doesn't provide a built-in > > solution to this problem. > > From the Ada83 manual "An implementation may (but need not) reclaim the > storage occupied by an object created by an allocator, once this object > has become inaccessible." > > The next section describes the CONTROLLED pragma to forbid implementations > from reclaiming memory except when leaving the innermost "block statement, > subprogram body or task body" enclosing the type declaration. > > Is the complaint that Ada should force implementors to reclaim storage, > or that when the CONTROLLED pragma is not used, implementations should > take a less conservative approach than waiting to exit the scope of the > type declaration? Ada83 took a 'see no evil, hear no evil,...' approach to storage management. Therefore, some of the vendors initially took the same (sloppy) attitude -- e.g., Rational, Telesoft, etc. It actually takes a great deal of sophistication for a language to offer automatic, safe, flexible, customizable memory management protocols -- this is probably why NO language today offers such a collection of features. >From the Ada rationale and the design of Ada, it was clear that automatic garbage collection was preferred and intended, but never implemented due to a veto from the intended embedded user community. Unfortunately, this left Ada in a never-never land where it didn't have _either_ automatic storage management _or_ not-so-automatic storage management. This general lack of 'fit and finish' in Ada83 seems more appropriate for consumer products from the old Soviet Union than one from the U.S.A. Given the nature of the process which produced Ada83, perhaps there is a lesson here?? -- www/ftp directory: ftp://ftp.netcom.com/pub/hb/hbaker/home.html