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,5dacec64c8c879fa
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.231.202 with SMTP id ti10mr169101pbc.5.1328754156884;
        Wed, 08 Feb 2012 18:22:36 -0800 (PST)
MIME-Version: 1.0
Path: 
 wr5ni3295pbc.0!nntp.google.com!news2.google.com!goblin1!goblin2!goblin.stu.neva.ru!newsfeed.x-privat.org!news.jacob-sparre.dk!pnx.dk!jacob-sparre.dk!ada-dk.org!.POSTED!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Preventing Unchecked_Deallocation?
Date: Wed, 8 Feb 2012 20:22:25 -0600
Organization: Jacob Sparre Andersen Research & Innovation
Message-ID: <jgvala$vpi$1@munin.nbi.dk>
References: 
 <33a35da4-6c3e-4ab4-b58f-a9d73565d79a@t30g2000vbx.googlegroups.com><ad427e2f-efdb-4e34-b4cf-ee55a3f8e9f5@f14g2000yqe.googlegroups.com><f4c34323-d0d8-4315-aaaa-31c0119e2ba4@n6g2000vbz.googlegroups.com><4350713b-6ac3-4b22-b221-8da2bac52fea@t5g2000yqk.googlegroups.com><26e4f2a4-edae-4e37-8697-f2390e636a21@z31g2000vbt.googlegroups.com><07915db7-0e84-4eb5-af69-ee31e10b018f@db5g2000vbb.googlegroups.com><ad11f6f6-f997-4d1d-a7cc-b7d3e333fdf9@f14g2000yqe.googlegroups.com><wcczkcu2uxh.fsf@shell01.TheWorld.com>
 <m262fi5llt.fsf@pushface.org><wccipjiqm2v.fsf@shell01.TheWorld.com>
 <m21uq567h7.fsf@pushface.org>
NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net
X-Trace: munin.nbi.dk 1328754154 32562 69.95.181.76 (9 Feb 2012 02:22:34 GMT)
X-Complaints-To: news@jacob-sparre.dk
NNTP-Posting-Date: Thu, 9 Feb 2012 02:22:34 +0000 (UTC)
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Date: 2012-02-08T20:22:25-06:00
List-Id: <comp.lang.ada>

"Simon Wright" <simon@pushface.org> wrote in message 
news:m21uq567h7.fsf@pushface.org...
> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
...
> Using limited types is one way of approaching this, but I suppose
> another would be apply conventions, such as insisting on 'in out' usage
> everywhere??? How do compiler writers deal with symbol tables?

I can't speak for others, but our records are non-limited. That makes them 
easy to copy for operations like generic instantiation and subprogram 
inheritance where you need to make a near duplicate of a part of a 
symbolable. We do have one record that is limited, and it has been a 
long-term pain to deal with.

OTOH, you'd probably not like the structure much. We didn't hide any 
significant part of the symboltable, because it didn't seem to pay -- there 
are hundreds of different values stored there, and pretty much any operation 
could use any of them. We did use some accessors, but that was solely for 
memory management reasons.

I'm not sure if we'd use the same structure if starting over today.

                                     Randy.