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.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,21960280f1d61e84
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Newsgroups: comp.lang.ada
Subject: Re: GC in Ada
References: <1169636785.504223.139630@j27g2000cwj.googlegroups.com>
 <m7ejpj5u9t.fsf@hod.lan.m-e-leypold.de>
 <u7iv8o16m.fsf@stephe-leake.org> <3pejpgfbki.fsf@hod.lan.m-e-leypold.de>
 <epkcru$fk2$1@cernne03.cern.ch> <njirepncb0.fsf@hod.lan.m-e-leypold.de>
 <eppn6r$m41$1@cernne03.cern.ch> <vwbqkffq94.fsf@hod.lan.m-e-leypold.de>
 <eputhf$p8u$1@cernne03.cern.ch> <dzsldoachu.fsf@hod.lan.m-e-leypold.de>
 <eq6v5b$bsb$1@cernne03.cern.ch> <l5iregra8a.fsf@hod.lan.m-e-leypold.de>
 <eq9gv3$dre$1@cernne03.cern.ch> <il64aftsq7.fsf@hod.lan.m-e-leypold.de>
 <eqa2j8$mfu$1@cernne03.cern.ch> <bpveifcmum.fsf@hod.lan.m-e-leypold.de>
 <eqc456$fp5$1@cernne03.cern.ch> <45c99c24$1@news.post.ch>
 <eqccdc$k89$1@cernne03.cern.ch> <45c9bdb8$1@news.post.ch>
 <eqekkj$hq1$1@cernne03.cern.ch>
From: Markus E Leypold
 <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>
Organization: N/A
Date: Thu, 08 Feb 2007 09:43:44 +0100
Message-ID: <n44ppxvy2n.fsf@hod.lan.m-e-leypold.de>
User-Agent: Some cool user agent (SCUG)
Cancel-Lock: sha1:ZbY6rlUHtbREoKxx4BFgeCzteEA=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
NNTP-Posting-Host: 88.72.239.230
X-Trace: news.arcor-ip.de 1170923915 88.72.239.230 (8 Feb 2007 09:38:35 +0200)
X-Complaints-To: abuse@arcor-ip.de
Path: 
 g2news2.google.com!news1.google.com!news.maxwell.syr.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!news-fra1.dfn.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail
Xref: g2news2.google.com comp.lang.ada:9182
Date: 2007-02-08T09:43:44+01:00
List-Id: <comp.lang.ada>


Maciej Sobczak <no.spam@no.spam.com> writes:

> Martin Krischik wrote:
>
>> And Unchecked_Deallocation should deallocate even when a collector
>> is present.
>
> I don't understand. There is no legal way for the program to verify
> that anything was indeed deallocated, so it doesn't make much sense to
> say that this behaviour is required.

Oh yes. Deallocating immeditately and deallocating later makes a
difference in time and space behaviour -- which IS measurable outside
the program (BTW: Exactly what you've been harping upon in you
opposition against GC :-)) )

Regards -- Markus