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-Thread: 108717,a7c8692cac750b5e X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: 103376,703c4f68db81387d X-Google-Attributes: gid108717,gid115aec,gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!newshub.sdsu.edu!logbridge.uoregon.edu!usenet01.sei.cmu.edu!bb3.andrew.cmu.edu!lmtp2nntp!not-for-mail From: "Arthur J. O'Dwyer" Newsgroups: comp.programming,comp.realtime,comp.lang.ada Subject: Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada)) Followup-To: comp.programming,comp.lang.ada Date: Sat, 12 Mar 2005 22:42:43 -0500 (EST) Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <112rs0bdr2aftdf@corp.supernews.com> <1inxxr988rxgg$.1w9dedak41k89.dlg@40tude.net> <112s1r0rf0o8nca@corp.supernews.com> <112sonip5v4dca6@corp.supernews.com> <112t3de6fu04f38@corp.supernews.com> <1110396477.596174.285520@o13g2000cwo.googlegroups.com> <112vb2t8eonuhed@corp.supernews.com> <1110422108.925127.54110@o13g2000cwo.googlegroups.com> <11329cb96h2p19f@corp.supernews.com> <113394jjvppao64@corp.supernews.com> <1133s3qnmqmbjfb@corp.supernews.com> <4232a9f7$0$26552$9b4e6d93@newsread4.arcor-online.net> <11369p5jrcc6835@corp.supernews.com> NNTP-Posting-Host: smtp.andrew.cmu.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Trace: bb3.andrew.cmu.edu 1110685363 29475 128.2.10.82 (13 Mar 2005 03:42:43 GMT) X-Complaints-To: advisor@andrew.cmu.edu NNTP-Posting-Date: 13 Mar 2005 03:42:43 GMT In-Reply-To: Xref: g2news1.google.com comp.programming:17893 comp.realtime:1405 comp.lang.ada:9286 Date: 2005-03-13T03:42:43+00:00 List-Id: On Sun, 13 Mar 2005, Jim Rogers wrote: > > CTips wrote in news:11369p5jrcc6835@corp.supernews.com: >> Oh, and just to illustrate another point about Ada, try running the Ada >> program equivalent to the following program: Source code below has been reformatted to save space and look prettier. I think regardless of CTips' and Jim's points in this thread, the original code serves as an excellent argument against using [] in function headers; the extra "documentation" is more than offset by the decline in readability, as far as I'm concerned. >> #define N 30000 >> #define N2 60000 >> >> void setup_array(int **x, int *p, int *q) >> { >> int i; >> for( i = 0; i < N; i++ ) { >> x[i] = &p[i]; >> x[i+N] = &q[i]; >> } >> } > > The function setup_array sets up the x array > so that the first N elements each individually > point to the elements of the p array, except for > the last element in the p array. The second N > elements of X point to the elements of the q > array, except for the last element of the q > array. Or: The first N elements of the x array refer to the N two-element slices of the p array, and the second N elements of the x array refer to the N two-element slices of the q array. >> void >> do_array( >> int * x[N2] >> ) >> { >> int i; >> int *p; >> for( i = 0; i < N2; i++ ) { >> p = x[i]; >> p[1] = i; >> } >> } > > do_array has p point to the ith element in x, > then treats p as an array and assigns its second > element the value i. "Treats p as an array" is a bit of meaningless C-bashing, in this context. What Jim means is "treats p as a pointer" (since the [] operator applies only to pointer values in C) --- and p /is/ a pointer! There's nothing suspect going on with the types here. > This sort of programming is generally foolishness. > x[i] points to an int. Ints are not the same as > arrays of ints. Not in Ada, no. I believe that was the point CTips was demonstrating with this code snippet: The same code, written in Ada, would be much longer, slower, and immensely more cumbersome for the reader. I don't know to what purpose one might put the demonstrated code, so I think it's kind of a silly example. The proper retort is, "Ah, but Ada wasn't designed for such nonsensical tasks! Show me a /useful/ algorithm where C is more expressive!" > Treating the address of any int > as the beginning of an array is a formula for buffer > overflow, as is demonstrated in this example. This example does not appear to contain any buffer oveflow. If you think it does, please point it out to me. I may have missed something. > I suspect you want a solution written as you would write > it in C. That is not quite reasonable. Each language has > its own best approach to a given problem. I chose to write > the Ada solution as a solution to what I understand is the > problem you are trying to solve. > > procedure Array_Pointers is > N : constant Positive := 30000; > > type Int_Array is array(Positive range <>) of aliased Integer; > type Int_Ptr is access all Integer; > type Element_Ptr is array(Positive range 1..N) of Int_Ptr; > type Combiner is record > P : Element_Ptr; > Q : Element_Ptr; > end record; > > procedure Do_Array(X : Combiner) is > PA : Element_Ptr; > begin > Pa := X.P; -- assign all elements of X.P to Pa Um... surely there's a better way to do this! Are you really copying N references here, or is something going on more subtle than the comment indicates? > Pa(2).all := 1; -- Assign 1 to the second value in the array For my own edification: Am I correct in thinking that the ".all" is superfluous in this expression? > Pa := X.Q; -- assign all elements of X.Q to Pa > Pa(2).all := 1; -- Assign 1 to the second value in the array > end Do_Array; > > P : Int_Array(1..N + 1); > Q : Int_Array(1..N + 1); > X : Combiner; > > begin > -- set up the combiner to point to the elements > -- in P and Q > for I in 1..N loop > X.P(I) := P(I)'access; > X.Q(I) := Q(I)'access; > end loop; > for I in 1..10_000 loop > Do_Array(X); > end loop; > end Array_Pointers; -Arthur