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,d1df6bc3799debed X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Not intended for use in medical, Date: 1997/05/13 Message-ID: #1/1 X-Deja-AN: 241280548 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <5kmek2$9re@bcrkh13.bnr.ca> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-05-13T00:00:00+00:00 List-Id: Robert Eachus claimed that there was no problem in writing a random number generator of the kind specified in the RM, and followed up my query about this with: << I guess we have different definitions of efficiency. Since for any decent random number generator the generator parameter will be a record that should be passed by reference, the fact that "pure" Ada may require the generator object to be on a heap (so the pointer can be passed as an in parameter) has no effect on the efficiency of the call to Random. Any overhead occurs in the creation and deletion of generator objects, which usually occurs once per program.>> Which makes it clear that he is quite happy with a random number generator that implicitly uses the heap -- and, he knows this surely, but forgot to mention it -- controlled types, since you have to be ssure that these implicitly allocated generators are properly freed when no longer needed. So here we have (a) implicit use of the heap, which may be a real problem in an environment which wants to avoid heap use completely, and in any case is problematic. For example, it means that pragma Restrictions (No_Implicit_Heap_Allocations); will cause the random number to be unavalable. (b) you drag in all the support stuff for controlled, and also introduce implicit finalization which you do not expect. This finalization could for example increase the latency on ATC at a critical point. All this because the language does not allow in-out parameters on functoin arguments. At least for GNAT, this is academic, because we certainly do not use the heap for random number generators (despite what Robert Eachus says, I don't consider this acceptable for a second). Instead we write the body using 'Unrestricted_Access which allows us to get the equivalent of in-out parameters in functions, although certainly not in a portable manner. I wonder what other Ada 95 compilers do, someone want to check Object Ada -- this is one case where they cannot be using the GNAT routine, since as far as I know they do nt provide Unrestricted_Access.