Re: Call by reference vs. call by value

[Felaco <bcf@swlpts1.ssd.ray.com>]

dewar@cs.nyu.edu (Robert Dewar) writes:

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

Of course I have to admit ignorance here.  I never really thought
about it in Ada.  For some reason I assumed that the compiler would in
some way ensure that this type of error would not occur, either by
passing the array by value, or reordering the assignments so the
problem would not occur.  I realize I expected too much.

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

Well, I guess I never conceived a machine might exist where call-by-
value for anything bigger than a word is more efficient than call by
reference, so my first instinct would be to dictate that
call-by-reference be used in all cases.  I believed the opposite was
true, however, because I wrongly thought that the designers of Ada
valued safety over performance, which is not really true.

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

Of course one should know a language well, but in this case the
language "wasn't very friendly".  My point about C/C++ is that the
programmer is forced to think about this issue immediately.  All
arrays are passed by reference, and all structs are passed by value -
no ambiguity about it.  You have to be aware of this to accomplish
anything in the language.  I learned of this problem within a month of
programming in C, but I've been using Ada for a year, and this is the
first time I've had this issue pop up.  Maybe this reflects poorly on
me, but what can I say!
 
> 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.

Sure, don't doubt it.  It makes perfect sense.

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

For the record, my recommendation is simply to clarify the issue.
It would be nice if there were no implementation defined behavior, in
a perfect computer world, but I'm not that naive.

One possibility that hasn't been explored is this: define the rule as
call-by-value *by default*, and give me a pragma or something to get
the more efficient call-by-reference behavior.  Then I would be forced
to be aware of the pitfalls.  It's not the greatest solution, but it
least it gives the programmer more control.
  
> 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.

That's exactly my point, it is defined by not being possible!

-- 
-------------------------------------------------------------------------------
Chris Felaco                               Phone: x4631 (Raynet 444, Local 842)
Raytheon Company                                         Email: bcf@ssd.ray.com
-------------------------------------------------------------------------------