Re: Access types vs. Record types as procedure parameters

[Robert Dewar <robert_dewar@my-deja.com>]

In article <37BC4F12.E33D50EE@gbr.msd.ray.com>,
  Andrew L Moore {66003} <alm@gbr.msd.ray.com> wrote:
> I am debating on whether to pass a record object to a
procedure or an access type to that record object.
>
> For example I have:
>
>      package body X is
>      type Record_Type;
>      type Array_Type is array (1 .. n) of Record_Type;
>      Array_Object : Array_Type;
>      procedure One;
>      procedure Two (Parameter : in Record_Type);
>      ---More procedures and functions
>      end X;
>      procedure One is
>      begin
>      for I in range 1 .. n loop
>            procedure Two(Parameter => Array_Object (I));
>      end loop;
>      end One;
>
----------------------------------------------------------------
----------------------

Almost certainly the code above is passing the record by
reference. It is basically very unlikely that the compiler
would do anything else. Of course it is always possible
that a compiler generate deliberately horrible code, but
very unlikely.

>      OR:
>      package body X is
>      type Record_Type;
>      type Array_Type is array(1 .. n) of Record_Type;
>      type Access_Type is access Record_Type;
>       Array_Object : Array_Type;
>      function Address_To_Pointer is new
> Ada.Unchecked_Conversion(System.Address, Access_Type);
>      procedure One;
>      procedure Two (Parameter : in Access_Type);
>      --More procedures and functions
>      end X;
>      procedure One is
>      Object_Ptr : Access_Type := null;
>      begin
>      for I in range 1 .. n loop
>
>          Object_Ptr :=
Address_To_Pointer(Array_Object(I)'Address)
>           procedure Two (Parameter => Object_Ptr);
>      end loop;
>      end One;

The above code is perfectly frightful. It is highly
implementation dependent (how do you know you can do
unchecked conversions between address and access types?)
Are you perhaps restricted to Ada 83, if so all the more
reason not to use nasty code like the above. If you are
using Ada 95, then of course get rid of the junk unchecked
conversion (*) and use 'Access and an access parameter.

(*) if you absolutely must convert addresses to access values,
which is as above totally unnecessary and undesirable in this
case anyway, please do it the proper way with address to
access conversions.
> I am looking for the way that would provide the greatest speed
of
> execution.  I know that passing a pointer to an object of a
record type
> is more efficient that passing the record itself,

You know wrong! Indeed most programmers who try to outguess
a compiler and write low level code in an attempt to be more
efficient just don't begin to know enough to make the right
choices. This post is in fact something like a text book
example of this in action. Since the record is almost certain
to be passed by reference, passing a record as an IN parameter
is likely to generate absolutely IDENTICAL code to passing a
pointer.

> but would that be
> negated by repeated calls to Unchecked_Conversion.

More complete nonsense, the calls to Unchecked_Conversion, if
they work at all, of course generate no code whatsoever. Indeed
it is quite likely that the code generated by the two pieces of
code above is byte for byte identical.

Once more, please don't try to outguess the compiler unless you
have some reasonable idea of what code is being generated. I
have no idea why you think Unchecked_Conversion would generate
code here, but clearly you are operating with some very
significant misconceptions.

> Basically, are there
> any advantages to using Unchecked_Conversion to get an access
value to
> an object to then pass it to a procedure.

None whatever! Please write code in the clearest most readable
most portable manner possible, and trust the compiler to
generate reasonable code. There are cases where a programmer
who really knows what they are doing can improve matters by
using low level techniques, but

a) this is not such a case!
b) you are not such a programmer!

You really will do MUCH better not to try to improve performance
in this kind of manner. For sure, you do horrible damage to the
quality of the code, and at best you are unlikely to change the
performance, at worst you can damage the performance if you do
not know exactly what you are doing!

> Any assistance you could provide would be greatly appreciated.

If the above seems a bit harsh, sorry, but this really was a
particularly gruesome suggested replacement :-)



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.