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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a00006d3c4735d70 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-09 08:36:39 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!news.gtei.net!newsfeed1.easynews.com!easynews.com!easynews!small1.nntp.aus1.giganews.com!border1.nntp.aus1.giganews.com!intern1.nntp.aus1.giganews.com!nntp.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 09 Jan 2004 10:36:38 -0600 Date: Fri, 09 Jan 2004 11:36:37 -0500 From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Certified C compilers for safety-critical embedded systems References: <3fe00b82.90228601@News.CIS.DFN.DE> <5802069.JsgInS3tXa@linux1.krischik.com> <1072464162.325936@master.nyc.kbcfp.com> <1563361.SfB03k3vvC@linux1.krischik.com> <11LvOkBBXw7$EAJw@phaedsys.demon.co.uk> <3ff0687f.528387944@News.CIS.DFN.DE> <1086072.fFeiH4ICbz@linux1.krischik.com> <3ff18d4d.603356952@News.CIS.DFN.DE> <1731094.1f7Irsyk1h@linux1.krischik.com> <3ff1b8ef.614528516@News.CIS.DFN.DE> <3FF1E06D.A351CCB4@yahoo.com> <3ff20cc8.635997032@News.CIS.DFN.DE> <3ff9df16.30249104@News.CIS.DFN.DE> <3FFC0201.6020303@noplace.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.34.214.193 X-Trace: sv3-10YNsnZYxdQiCaeN0v+suc4wSHQT71/8hmXsm4EyQZ3+lj0E3oZMdUovGzFrgIQXGbcQgo7GKn0miaz!WDOO71U0aDpQCkLYwBXgEtGZr9kTb4B1v26vBqHbjpjkNEhC+Fqd1DD3YO8pag== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:4259 Date: 2004-01-09T11:36:37-05:00 List-Id: Frank J. Lhota wrote: > Was there any discussion of using access types, i.e. > > function Random (Gen : access Generator) return Result_Subtype; > > This would require that each generator is aliased, and that 'Access > attributes be used, but at least this would give some recognition to the > fact that the generator is changed by the call. Actually, and I think more interesting, was that we discussed making the generator parameter implicit, and having a per task generator value. That idea was dropped because some people thought it would make calls to Random slower, and others were worried that it would force all compilers to support per task variables. Per task variables did make it into Ada 9X, but there is no standard way to use them with random number generators. I keep promising myself that someday I will have to write a generic that does that, but it seems like using a sledgehammer to swat a fly. Every time the issue comes up, it is easier to create a new generator object inside each task. But notice that having a "default" generator would be either error prone in the presense of tasking, or slow because references would have to be via a protected object whether or not a program used random numbers in more than one task. We avoided that mistake, and not by accident. But it does create this anomaly that the "normal" random number generator interface does have this weird side effect on its parameter. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush