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,LOTS_OF_MONEY
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,93ab7fc5388e249
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-12-06 09:41:00 PST
Path: 
 archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!newsfeed.direct.ca!look.ca!wn1feed!worldnet.att.net!204.127.198.204!attbi_feed4!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail
From: "Mark Lundquist" <mlundquist2@attbi.com>
Newsgroups: comp.lang.ada
References: <DzdP7.48986$xS6.81471@www.newsranger.com>
 <hRdP7.49017$xS6.81420@www.newsranger.com> <3C0E1FA1.45A38A75@brighton.ac.uk>
 <%7sP7.49836$xS6.82296@www.newsranger.com> <aewP7.2149$dp6.152302@rwcrnsc54>
 <DpxP7.50285$xS6.83694@www.newsranger.com> <DxyP7.309$w85.20109@rwcrnsc54>
 <CALP7.51313$xS6.84388@www.newsranger.com>
Subject: Re: Iterator approach (was: List container strawman 1.3)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID: <M4OP7.1278$L51.9683@rwcrnsc54>
NNTP-Posting-Host: u4OP7-12031-L51-11146@rwcrnsc54
X-Complaints-To: abuse@attbi.com
X-Trace: rwcrnsc54 1007660460 u4OP7-12031-L51-11146@rwcrnsc54 (Thu,
 06 Dec 2001 17:41:00 GMT)
NNTP-Posting-Date: Thu, 06 Dec 2001 17:41:00 GMT
Organization: AT&T Broadband
Date: Thu, 06 Dec 2001 17:41:00 GMT
Xref: archiver1.google.com comp.lang.ada:17518
Date: 2001-12-06T17:41:00+00:00
List-Id: <comp.lang.ada>


"Ted Dennison" <dennison@telepath.com> wrote in message
news:CALP7.51313$xS6.84388@www.newsranger.com...
> In article <DxyP7.309$w85.20109@rwcrnsc54>, Mark Lundquist says...
> >In the access discriminator way, any state of affairs that could give
rise
> >to a dangling iterator results in a compile-time error, and the safety
comes
> >at no added run-time expense.  The chained iterator approach results in a
>
> I don't think that's true at all. Suppose I have the following (using your
> example):
>
>    type List_Ptr     is access My_Lists.List;
>    type Iterator_Ptr is access My_Lists.Iterator;
>    function Free is new Unchecked_Deallocation (My_Lists.List, List_Ptr);
>    function Free is new Unchecked_Deallocation (My_Lists.Iterator,
> Iterator_Ptr);

I guess that's why they call it "unchecked" deallocation :-) :-).

OK, so I shouldn't have said it was safe under "any" circumstance permitted
by the language...

But I don't think Unchecked_Deallocation can ever be made safe, because of
pointer aliasing:

    Lost : List_Ptr := List;
    .
    .
    Free (List);
    Do_Something (Lost);

I guess my view is that using Unchecked_Deallocation is like signing a
waiver that says "I accept full responsibility for whatever happens".  So a
high-overhead scheme to protect the user from any bad consequence of that
seems to me not to be in the right spirit, or something like that.

Just one person's opinion... :-)

-- mark