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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8e64f4db20d57eb5 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Call by reference vs. call by value Date: 1996/07/20 Message-ID: #1/1 X-Deja-AN: 169902364 references: <31F10E50.726@egr.uri.edu> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-20T00:00:00+00:00 List-Id: 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.