Re: Call by reference vs. call by value

[dewar@cs.nyu.edu (Robert Dewar)]

Chris said

   This is somewhat of a pain
   at times, but at least it is obvious and clearly defined.  I had no idea
   that Ada's behavior was undefined and wrongly assumed that in parameters
   were always passed by value.

Well you can always get bitten by not knowing a language rule that is
clear, and you can always be surprised if you wrongly assume something!
Ada's behavior is not undefined, it is implementation defined (there is
an important difference!)

It is quite odd to assume that all IN parameters are passed by value, do
you really expect million element arrays to be copied when they are passed
to procedures, I think not.

   I realize that the solution to this problem in this case is to simply
   make one assignment using an array aggregate, or change the procedure to
   a function.  I have recommended this course of action.  I still think
   that this type of error should not occur.  In many situations, the
   solution may not so simple.  Ada's behavior should not be so
   "implementation dependent".

Here is a case where the language semantics is non-deterministic for
efficiency reasons. To force call by value in all cases would be clearly
unaccepable for large arrays. On the other hand, to force call by
reference is also inefficient on some machines. Yes, the semantics would
be cleaner if there were no implementation dependence here, but efficiency
issues certainly cannot be ignored.

The question is, does someone who knows Ada get into trouble with this rule?
Clearly if you don't know a rule in the language you can always get into
trouble, you can't expect Ada to automatically correct your misconceptions
about the language. This is certainly a lesson that you need to know a
language well to avoid trouble, but it is not convincing that there is a
problem here.

Actually, I think most people who make a mistake here make a mistake the
other way round, they assume that arrays (and even records) have to be
passed by reference. The same thing happens in Fortran (which shares Ada's
approach of leaving it up to the implementation to decide whether to pass
by copy or reference) -- people often assume Fortran requires by-reference.

You actually remember the GNAT situation wrong, and if you remembered it
right, it would have reminded you of the issue. We changed record passing
from being by reference for large records to being always by value, as you
would like to see. This turned out to be completely unacceptable in some
situations because of severe degradation of performance -- so this is a
nice object lesson that your recommendation is infeasible!

P.S. we also got quite a few complaints of regressions that turned out to  be
people assuming that records were passed by reference, and their programs
depended on reference semantics!

P.P.S. In C++ you can't pass arrays anyway so the issue does not arise, so it
is wrong to say that the mechanism for this is defined in C++! If you cold
pass arrays in C or C++, then the same problem would arise.