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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e80a1497a689d8a5 X-Google-Attributes: gid103376,public From: Charles Hixson Subject: Re: Ada and GC. Was: Re: Ammo-zilla Date: 1999/11/03 Message-ID: <38206BA1.3C1D7E79@mail.earthlink.net>#1/1 X-Deja-AN: 544017106 Content-Transfer-Encoding: 7bit References: <38120FAF.945ADD7D@hso.link.com> <7uutgd$87h$1@nnrp1.deja.com> <19991024.18033546@db3.max5.com> <38189268.43EB150F@mail.earthlink.net> <86ogdjtdwz.fsf@ppp-115-70.villette.club-internet.fr> <7vadsp$8q61@news.cis.okstate.edu> <1999Oct28.221910.1@eisner> <7vb3c4$8a21@news.cis.okstate.edu> <7vhg2n$7ht$1@nnrp1.deja.com> <7vht9i$a2g1@news.cis.okstate.edu> <381DD258.B6B11153@averstar.com> <7vmk27$p37$1@nnrp1.deja.com> <381F7FFA.FFF5A906@mail.earthlink.net> <7vocct$3hq$1@nnrp1.deja.com> X-Accept-Language: en X-Posted-Path-Was: not-for-mail Content-Type: text/plain; charset=us-ascii X-ELN-Date: 3 Nov 1999 17:06:46 GMT X-ELN-Insert-Date: Wed Nov 3 09:15:08 1999 Organization: MTC Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-11-03T00:00:00+00:00 List-Id: Well... I was thinking that within the {Pragma GC} packages at a minimum the compiler should be able to readily determine which items were pointers and which were not. This would put contraints on type casts (generally a good thing anyway, even if they are sometimes needed), etc. Actually, I was thinking of imposing even stronger limitations, (only manage storage allocated within the package, pass return values out as function values, but no direct access allowed, no publicly visible access variables, any child packages to be subject to GC constraints, etc.). Even if the packages are limited in this manner, most of the advantages of GC can be obtained. If they aren't all needed, then so much the better. The idea here is, when one wants to make use of an efficient GC, then one adopts such constraints as are necessary to make it easy and efficient. But one is able to freely link it to other sections of code that don't have those constraints, so that one can do the parts that it would be difficult to do in the limited framework in a more liberal environment. One just needs to be much more careful with allocated storage when not inside the GC section of the code. And, yes, their use of memory would be nearly disjoint. But this would allow much simpler algorithms to be used for lattice memory structures, etc. And would allow most of the code to be written in the normal manner. I may feel that code would tend to migrate to the GC section, but this would not be a necessity, and certainly the non-GC sections of the code could be expected to be faster. Robert Dewar wrote: > In article <381F7FFA.FFF5A906@mail.earthlink.net>, > Charles Hixson wrote: > > This would allow dynamic constructions that were isolated into > separate > > packages to co-exist with their more consicously manipulated > brethern > > within the same program. > > I don't see how this will help at all unless you partition > memory into sections that cannot contain mutual pointers ... > > Sent via Deja.com http://www.deja.com/ > Before you buy.