Re: 10 rules for benchmarking (was Re: Teaching new tricks to an old dog (C++ -->Ada))

["jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>]

Arthur J. O'Dwyer wrote:
> On Sun, 13 Mar 2005, Jim Rogers wrote:
> > 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!"

 On the other hand I have read arguments in comp.lang.c where some
C-bashing person tries to claim that pointers and arrays in C
are indistinguishable. The C faithful clearly stated that there is
a difference. I was trying (however poorly) to restate that position.
A pointer to an int is used to pass either an int by reference,
or the pointer to an array of int. The parameter passed is not
an array, but the address of the start of the array. Unfortunately,
the way many people write C it is not possible from inside a called
function to determine whether the address passed was really to an
array of int, or to a single int. The function is left to make
assumptions about this issue.

>
> > 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.
>

Ok, I understand why he made p and q with N+1 elements.
This allows him to point past the Nth element without
leaving either p or q's allocated space. Nonetheless,
the data element in the highest position of those arrays
has not been initialized. This is not the best practice.

>
> > 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?

That is exactly what I am doing, which matches nicely with the
actions taken in the C code for the function setup_array:

void
setup_array(
     int * x[N2],
     int   p[N+1],
     int   q[N+1]
     )
{
  int i;
  for(i=0; i< N;i++){
   x[i]-&p[i];
   x[i_N]=&q[i];
  }
}

This appears to also be copying two sets of N pointers.

>
> >      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?
>

Not at all. This is equivalent to the C syntax
   *(p[1]) = 1;


Jim Rogers