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,803df5f3f60558d5 X-Google-Attributes: gid103376,public From: dewar@cs.nyu.edu (Robert Dewar) Subject: Re: Is 'out' different from 'in out' (Was: Uninitialized "out" parameters) Date: 1996/07/23 Message-ID: #1/1 X-Deja-AN: 170446589 references: <31EEACDA.64880EEB@sage.inel.gov> organization: Courant Institute of Mathematical Sciences newsgroups: comp.lang.ada Date: 1996-07-23T00:00:00+00:00 List-Id: Michael said "They all confirm what I was not entirely sure to understand correctly. There is no essential difference between 'out' and 'in out' parameters, and it is probably worth considering them to be the same thing. IMHO, it was a mistake of the 9X design. It's too late to repair. Possible useful style rule : avoid 'out' parameters, since they are error-prone, and prefer 'in out'." First, they confirmed no such thing. Out and in-out are VERY different for scalars, as several of the posts emphasized. In particular, using in-out unnecessarily causes the caller to generate unncecessary code to initialze the input value. I would actually consider a program that passed an uninitialized variable as an in parmeter to be violating the spec of a subprogram. As for suggesting a style rule to avoid 'out' parameters, I strongly object quite independently of the above concerns. The use of OUT as a mode is a clear and important part of the documentation of subprograms. In general we document the input-output behavior of a procedure. The IN and IN OUT parameters describe the input requirements, the OUT and IN OUT parameters describe the outputs. It is a bad confusion to take an OUT parameter and convert it to IN OUT. As for out parameters being error-prone, this seems nonsense to me. Are you still worrying about the possibility of the variable being uninitialized on entry? Well making it an in out parameter doesn't change that, because an uninitialized variable can be passed in. However, it DOES stop the compiler from issuing some obvious warnings. SUppose we have procedure x (a : out integer) is begin a := a + 1; ... now any reasonable compiler will give a warning. But if you gratuitously change the parameter to in out, no warning is possible. Of course it is possible that the compiler might be able to warn you about passing uninitialized variables as inputs to this procedure. However, if this is a parameter which really conceptually is an out parameter, which you have gratuitously changed to in out, then these warnings are of course conceptually incorrect. This is definitely NOT an idea that flies!