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,b307bd75c8071241 X-Google-Attributes: gid103376,public From: "Samuel A. Mize" Subject: Re: newbie Q: storage management Date: 1997/05/05 Message-ID: <336E10BD.41C6@magellan.bgm.link.com>#1/1 X-Deja-AN: 239551520 References: <5k5hif$7r5@bcrkh13.bnr.ca> <336754A0.41C6@magellan.bgm.link.com> <336A065B.41C6@magellan.bgm.link.com> Organization: PSI Public Usenet Link Newsgroups: comp.lang.ada Date: 1997-05-05T00:00:00+00:00 List-Id: Robert Dewar wrote: > > Samuel Mize said > > < deallocation, which was designed for Ada 83, not Ada 95. If that > was unclear, I apologize. The design decision was carried over into > Ada 95 by (1) the vocal minority who fear dynamic memory usage, > (2) the requirement for upward compatibility, and (3) inertia. (See > also below about "special needs annexes" before flaming.)>> > > Actually this is quite wrong. Samuel, you were not there, and so you > are guessing, and you are guessing wrong! Perhaps true. However, > < deallocation, specifically why it's harder to use than "new" and is not defined to actually do anything. I wasn't referring, in this paragraph, to garbage collection. Unfortunately, I put a side point about GC into my post before continuing my main thrust, and this misled you. Sorry. Your discussions about the design reasons behind these points (requiring a generic instantiation of U_D, not requiring U_D to do anything) have been very helpful. Thank you. Sam Mize -- Samuel Mize (817) 619-8622 "Team Ada" -- Hughes Training Inc. PO Box 6171 m/s 400, Arlington TX 76005