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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6a0391eb7e0327d5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-08 18:12:16 PST Newsgroups: comp.lang.ada Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!nntp-relay.ihug.net!ihug.co.nz!newshosting.com!news-xfer1.atl.newshosting.com!uunet!dca.uu.net!ash.uu.net!world!news From: Robert A Duff Subject: Re: Ada style of passing 'in' parameters considered dangerous? User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Sender: news@world.std.com (Mr Usenet Himself) Message-ID: Date: Sun, 9 Feb 2003 02:11:27 GMT Content-Type: text/plain; charset=us-ascii References: <86isvuzabx.fsf@hoastest1-8c.hoasnet.inet.fi> <0th1a.41024$zF6.2804045@bgtnsc04-news.ops.worldnet.att.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Organization: The World Public Access UNIX, Brookline, MA Xref: archiver1.google.com comp.lang.ada:33923 Date: 2003-02-09T02:11:27+00:00 List-Id: "James S. Rogers" writes: > Not at all. > > In Ada an IN parameter is treated as a constant within the subprogram > it is passed to. This eliminates the ability to shoot yourself in the foot > with an IN parameter. Unless the actual parameter is aliased with some global, or some other parameter (of mode 'in out' or 'out'). >... An OUT or IN OUT parameter can be passed > by value or by reference. The language provides no rules about this. > The difference between the two in Ada is that an OUT parameter > has no reliable initial value, while an IN OUT parameter does. > In fact compiler writers are quite reasonable about their chosen > passing mechanisms. In general, any value larger than a register > is passed by reference. All other values may be passed by copy > or by reference. The rule is that elementary types are passed by copy (including copy-out in the 'in out' or 'out' case). Arrays and records leave the compiler a choice (except in the case of limited types). And that choice can make a difference in the behavior of the program, unfortunately. > There can be no race condition for either situation in a normal > subprogram, since the called subprogram will execute in the > same task as the calling subprogram. The issue arises without any multi-tasking. But in the multi-task case, it's even worse: an integer is passed by copy (thus no other task can meddle with the actual), but a record containing a single integer might be passed either way. > Calling a task entry may involve passing data. This is a form > of communication between tasks. In Ada this happens as part > of a "rendezvous", where the two tasks synchronize at the point > of communication, again eliminating a race condition. > > Calling a protected operation is another option for inter-task > communication. Again, protected operations execute within > the calling task, or its proxy in the case of protected entries. > > I have never seen a case where Ada parameter modes have > shot the programmer in the foot. Would it not be better if we could say, "It is not possible to shoot oneself in one's foot"? >...Ada parameter passing modes > are a lot safer to use than the rules found for Java. Yes, in Java everything's a pointer, so any procedure can modify any of its parameters (more or less). Ada is better in that regard. >... In Java all > primitive types are passed by value and all objects are passed > by reference. You have no choice. This does cause genuine > problems in program design for Java, particularly when you > want to modify the value of a primitive parameter. Since it is > impossible to pass an object by value you have the ever present > danger of unexpected side effects in Java method calls. > > Java does not have a direct equivalent of the Ada rendezvous, > nor does it provide an equivalent of Ada protected operations. > Java produces concurrency with a lot more surprises. > > Jim Rogers - Bob