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,a1a88c4d509f6381 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: scope and/or parameters (beginner) Date: 1999/04/14 Message-ID: <7f2435$54d$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 466269588 References: <37064309.889106243@news.dsuper.net> <37084459.8616007@rocketmail.com> <370b0c99.1137352783@news.dsuper.net> X-Http-Proxy: 1.0 x1.dejanews.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Apr 14 13:10:02 1999 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.04 [en] (OS/2; I) Date: 1999-04-14T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: > The rule in some other languages (eg Pascal and C) is > different -- in those languages, a parameter acts just > like a local variable, so you can modify it, and it > doesn't affect the caller's copy. That's error prone, > which is why in Ada an 'in' mode parameter acts like a > local *constant*. To expand on Bob's point, there is a fundamental issue here of binding. In Ada, a programmer knows that an IN parameter is bound to the actual argument, so if you have an IN parameter called Clunk, then throughout the code of the procedure you know that Clunk is bound to this value. In C or Pascal, if you see Clunk, it may or may not have the value of the input parameter, you have to carefully check the *dynamic* sequence of execution of the function to see if there could have been any modifications. Yes, it's slightly annoying to a writer who wishes to minimize keystrokes to have to declare a variable where a variable is needed, and initialize the variable with the value of the parameter. Too bad, we don't care about writers with slow fingers in the Ada world. We are worried about the reader (e.g. a maintenance programmer) coming to the program later, and being able to make simple assumptions (in this case that Clunk really is the input parameter) without having to check. For example, suppose we add a new rule to the interface. It says, if all other verification tests pass, then the parameter Clunk must be checked to make sure it does not have the value 43, and if it does, then raise the exception "End_Of_The_World". This is a relatively easy modification, you just look through the code to make sure you are past the validation checks, and then you add: if Clunk = 43 then raise End_Of_The_World; end if; You do nt have to worry about whether details of the code you skipped reading carefully do or do not change the value of Clunk. A C programmer making the same choice would have two approaches. a) carefully check the code to see if clunk is modified. This involves worrying about aliases (did someone do & on clunk, and pass this to a routine that might use the pointer to modify the value for example). Then if the answer is no, put in the above code, with a big warning message that no one must subsequently modify Clunk before this point. b) throw in an extra variable Clunk2, copy Clunk to Clunk2 at the start of the function. Put in a big warning that Clunk2 should not be modified, and then check Clunk2 at the appropriate point. Which do you think would be chosen (I would guess neither, C programmers (and programmers in general for that matter) are not in the habit of putting big warnings in their code! Robert Dewar -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own