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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ce0900b60ca3f616 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-02 18:21:19 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!crtntx1-snh1.gtei.net!lsanca1-snf1!news.gtei.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3BE35498.9F6381A2@acm.org> From: Jeffrey Carter X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: List container strawman References: <9rti6v$hcu$1@news.huji.ac.il> <1EyE7.10050$xS6.13527@www.newsranger.com> <9rue9f$j4t$1@nh.pace.co.uk> <9ruiet$kqg$1@nh.pace.co.uk> <3BE3235D.E292B890@boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 03 Nov 2001 02:21:24 GMT NNTP-Posting-Host: 209.86.205.132 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 1004754084 209.86.205.132 (Fri, 02 Nov 2001 18:21:24 PST) NNTP-Posting-Date: Fri, 02 Nov 2001 18:21:24 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Fri, 02 Nov 2001 18:17:22 PST (newsmaster1.prod.itd.earthlink.net) Xref: archiver1.google.com comp.lang.ada:15714 Date: 2001-11-03T02:21:24+00:00 List-Id: Matthew Heaney wrote: > > "Jeffrey Carter" wrote in message > news:3BE3235D.E292B890@boeing.com... > > Another place where some compiler writers use tricks is the interaction > > between a random number Generator value and the Random function. The > > generator holds the state data for the algorithm, which are supposed to > > be updated when a number is generated. You can implement Generator as a > > controlled type with a pointer to the state data, but again other tricks > > are possible from within the compiler. > > Why would you need to implement type Generator as a Controlled type? > Generator state is allocated on the stack, so Finalization is not required. > Allocating state on the heap and using Controlled Finalization would be a > horribly inefficient way to implement that type. The obvious way to modify an in parameter is to have it be an access value and change what it points to. You would want this to be Controlled so you could deallocate the storage when an object of the type goes out of scope. The GNAT implementation says -- The design of this spec is very awkward, as a result of Ada 95 not -- permitting in-out parameters for function formals (most naturally -- Generator values would be passed this way). In pure Ada 95, the only -- solution is to use the heap and pointers, and, to avoid memory leaks, -- controlled types. > > No heap allocation or compiler magic is needed to implement Generator; just > use the Rosen Trick: Yes, that is a trick that can be used (although your example has a couple of errors). Was it known before standardization? I somehow suspect it would have been outlawed if it were. GNAT uses type State is ... type Generator is limited record Gen_State : State; end record; Following the above quote, they add -- This is awfully heavy, so what we do is to use Unrestricted_Access to -- get a pointer to the state in the passed Generator. This works because -- Generator is a limited type and will thus always be passed by reference. type Pointer is access all State; function Random (Gen : Generator) return Uniformly_Distributed is Genp : constant Pointer := Gen.Gen_State'Unrestricted_Access; and then modify Genp.all. Since 'Unrestricted_Access is an implementation-dependent attribute, I think this qualifies as a trick, too. I wonder if there is some advantage to this trick over the Rosen trick. -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail