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: Felaco Subject: Re: Call by reference vs. call by value Date: 1996/07/30 Message-ID: #1/1 X-Deja-AN: 171129369 sender: news@ssd.ray.com (Administrator) x-nntp-posting-host: swlpts1.ssd.ray.com references: <31F10E50.726@egr.uri.edu> organization: Raytheon Electronic Systems - Software Engineering Laboratory newsgroups: comp.lang.ada Date: 1996-07-30T00:00:00+00:00 List-Id: bobduff@world.std.com (Robert A Duff) writes: > Felaco wrote: > >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. > > Yes, that's one reasonable solution. It shouldn't be a pragma, but > should use some sensible syntax. Some Pascal compilers do something > like this -- there are by-value parameters, and CONST parameters (which > are by-reference, but still in-mode), and VAR parameters (which are > by-ref/in-out). Maybe CONST parameters are part of standard Pascal now; > I don't know. Anyway, this solution has some problems (passing of > components of packed things, forcing the programmer to specify something > that *usually* doesn't matter, ..) I disagree with changing the syntax. I feel that the pragma is the least intrusive way of giving the programmer some control, but not forcing the programmer to care when they wouldn't otherwise. Another even simpler idea is to dictate that the compiler issue a warning when a call is made to a subunit with the same actual parameter used as an 'in' and an 'out' (or 'in out'). How hard would this be? > The SPARK subset of Ada solves the problem by making sure you can't > write code that can tell the difference between by-copy and by-ref. In > particular, exception handling is not allowed, and aliasing of > parameters is not allowed. This leads to a pretty restricted version of > the language, though. I keep seeing SPARK mentioned in this thread. Although I don't think I like the sounds of it, where can I get more info about this? (Feel free to send direct e-mail rather than post a response.) dewar@cs.nyu.edu (Robert Dewar) writes: > If you want to think more about this issue, worry about packed arrays > too. Requiring call by reference would mean that ALL packed arrays have > to be passed using general bit pointers, which would be unacceptably > inefficient in the normal case where slices are not passed. Same > thing for records, all records would have to be passed by bit address, > just in case the record you are passing is a field in a rcord with a > record rep clause. That's a good question - just how does the compiler determine how to pass array parameters where rep specs or packing applies? Does it use bit pointers, or does it just make a properly aligned copy and pass it along? If the LRM dictated that all arrays were passed by reference, then the compiler could decide to use bit pointers (if the architecture provided efficient means to do so) or it could just resort to making a copy and passing a reference to it. In the latter case, the programming pitfall I am trying to avoid is impossible, but the programmer would still know to program defensively because the rule says arrays are passed by reference. This is not great, but slightly better. I still think there is some merit to my suggestion, but I won't defend it beyond that. It just seems strange to me that the language designers went to such lengths to restrict the usage of access types, but they failed to address this type of programming error which I feel is even more insidious. -- ------------------------------------------------------------------------------- Chris Felaco Phone: x4631 (Raynet 444, Local 842) Raytheon Company Email: bcf@ssd.ray.com -------------------------------------------------------------------------------