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.73.229 with SMTP id o5mr643315pbv.7.1328772483893; Wed, 08 Feb 2012 23:28:03 -0800 (PST) Path: wr5ni4053pbc.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!newsfeed1.swip.net!85.214.198.2.MISMATCH!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Simon Wright Newsgroups: comp.lang.ada Subject: Re: Preventing Unchecked_Deallocation? Date: Thu, 09 Feb 2012 07:28:03 +0000 Organization: A noiseless patient Spider Message-ID: References: <33a35da4-6c3e-4ab4-b58f-a9d73565d79a@t30g2000vbx.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> Mime-Version: 1.0 Injection-Info: mx04.eternal-september.org; posting-host="dFCm8HWntFqmDIilBLqEJQ"; logging-data="28640"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19o4qv1MsgmTTi6egyihffQ8wwanUYZxQA=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (darwin) Cancel-Lock: sha1:MYaxPqtrF/Le9y6/bzgsPBYOUQg= sha1:L2xAuP2PLKDc+wmP8UqzWxQRia0= Content-Type: text/plain; charset=us-ascii Date: 2012-02-09T07:28:03+00:00 List-Id: "Randy Brukardt" writes: > "Simon Wright" wrote in message > news:m21uq567h7.fsf@pushface.org... >> Robert A Duff 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? [...] > 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. Sounds like a good scheme to me; 'private' isn't a bad default position, but common sense needs to rule!