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-Thread: a07f3367d7,344faf475a6f812a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.178.205 with SMTP id bn13mr20800014qab.3.1366661501783; Mon, 22 Apr 2013 13:11:41 -0700 (PDT) X-Received: by 10.50.43.225 with SMTP id z1mr1715202igl.9.1366661501719; Mon, 22 Apr 2013 13:11:41 -0700 (PDT) Path: ef9ni9516qab.0!nntp.google.com!gp5no4888351qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 22 Apr 2013 13:11:41 -0700 (PDT) In-Reply-To: <1b3buvosg9fcq$.z1uq1tdfril2$.dlg@40tude.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 69.20.190.126 References: <97967083-d21d-4de2-aeb8-76d0d5818993@googlegroups.com> <1b3buvosg9fcq$.z1uq1tdfril2$.dlg@40tude.net> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Interresting difference in Normal-Returns/Expression-Functions and Extended-Returns. From: Shark8 Injection-Date: Mon, 22 Apr 2013 20:11:41 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2013-04-22T13:11:41-07:00 List-Id: On Monday, April 22, 2013 1:13:47 PM UTC-6, Dmitry A. Kazakov wrote: > On Mon, 22 Apr 2013 11:27:09 -0700 (PDT), Shark8 wrote: >=20 > > I recently ran into unexpected behavior in the differences between a > > normal return and an extended return [in GNAT]: namely an extended retu= rn > > used to generate items in an array of tasks will *ALWAYS* execute in a > > sequential manner whereas the array generated with an expression-functi= on > > or normal return is executed simultaneously. > >=20 > > Is there some subtle difference in the extended return that I'm unaware= of? (Is this a bug?) >=20 >=20 > No difference (tested under Windows). Here's some output: C:\Programming\Projects\temp\Experiment.exe TEST_1: Expression Function Dave 0.133781955 Bob 0.304577380 Joey 0.536659479 Steve 0.699105740 TEST_2: Normal Return Function Joey 0.226854607 Dave 0.444059044 Steve 0.499072224 Bob 0.636090755 TEST_3: Extended Return Function Bob 0.566724062 Steve 0.118256144 Dave 0.442499906 Joey 0.711671948 Terminating. [2013-04-22 14:00:45] process terminated successfully (elapsed time: 03.35s= ) Notice that the second column (delay-time) of the first two test-cases is *= ALWAYS* sorted in ascending order, this is as expected; the difference is t= he last test-case which is *NOT* in ascending order. > Issues with the code: >=20 > 1. Add 2 s delay in each test in order to see all tasks completed. ... that's not an issue; they're all completing. > Delay > also causes context switching. When you use null statement the main task > likely to manage to create all contestant before any of them gains the > processor (depending on OS settings and number of cores available).=20 I have four cores; that shouldn't be a problem though -- I'm using the prot= ected object to manage my text-output debugging. > 2. The code leaks memory. I am sure you know that. It's rather irrelevant insofar as I know; this is only to illustrate that t= ask-accesses are behaving differently with normal returns than they are for= extended returns. > 3. Do not return anonymous access objects created by allocator new. It is > almost always a bug. Yeah, adding a named access-type probably would clean up the code a little. > 4. Keywords to be written all lower case, if you want others be able to > read your code. ... and here I thought we had these nifty tools for formatting source-code = according to the user's preference. It is not my fault these aren't well-in= tegrated into your IDE/text-editor. -- IOW, if casing mattered I'd expect i= t to be enforced by the language.