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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,147f221051e5a63d X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!y21g2000hsf.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: memory management in Ada: tedious without GC? Date: Mon, 19 May 2008 14:21:56 -0700 (PDT) Organization: http://groups.google.com Message-ID: <8d288545-e0c6-4f70-b3d5-3d037ab0bff2@y21g2000hsf.googlegroups.com> References: <4ddef8bf-b5b1-4d7e-b75b-386cd6c8402c@l17g2000pri.googlegroups.com> <482E8A9D.5040401@obry.net> <8640a12f-da99-435f-8eb6-372e175cd5b9@z72g2000hsb.googlegroups.com> <482F19CE.7060306@obry.net> <87d4nkzhtn.fsf@willow.rfc1149.net> <2545491.n7xu0MFufK@linux1.krischik.com> <5209773.UsCT0IWhbo@linux1.krischik.com> <82e2924a-4888-4b45-a4de-f33f905334c2@n1g2000prb.googlegroups.com> <155a4acc-8898-4316-88df-0b161bdadd9a@c58g2000hsc.googlegroups.com> <5f570e87-fd87-48cb-b991-a76c30648e79@y38g2000hsy.googlegroups.com> NNTP-Posting-Host: 85.3.224.28 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1211232117 32404 127.0.0.1 (19 May 2008 21:21:57 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 19 May 2008 21:21:57 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: y21g2000hsf.googlegroups.com; posting-host=85.3.224.28; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:259 Date: 2008-05-19T14:21:56-07:00 List-Id: On 19 Maj, 17:37, Matthew Heaney wrote: > > 1. No support for exception-safe assignment in Ada. > > It depends on how you define "exception-safe". I meant strong safety (either all OK or nothing modified). > Assignment in Ada > makes only a "basic guarantee" wrt exception safety Yes. > (State is not preserved > because finalization of the LHS happens before the assignment proper.) Note also that it prevents some obvious optimizations like avoiding memory allocator round-trip when for example short container is assigned to a longer one, which already has enough place for RHS. > > 2. Memory leak after exception is raised while initializing the > > allocated object in Ada. > > If by "initializing" you mean invoking a controlled action I meant initialization of components like here: type T is record X : Integer := Initialize_Me; end record; It can be any exception other than Program_Error, including user- defined one. > I do forget the exact rules about memory reclaimation, though; > if I do > this: > > declare > P : T_Access := new T; > begin > > and the initialization of the object designed by P fails (e.g. because > controlled initialization fails, which raises Program_Error, or > because component initialization fails, which raises > Constraint_Error), then what does the language say about reclaiming > the memory allocated for P.all? The memory is lost. OK, it is still managed by the relevant storage pool - but if the pool itself is not dynamically scoped (or the scope is just too wide), then it is effectively a leak. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com