"out" and "in out"

"out" and "in out"

[zork]

Hi i found the following explaination:

In Ada, "in" parameters are similar to C++ const parameters. They are
effectively read-only within the scope of the called subprogram.
Ada "in out" parameters have a reliable initial value (that passed
in from the calling subprogram) and may be modified within the scope
of the called procedure. Ada "out" parameters have no reliable
initial value, but are expected to be assigned a value within the
called procedure.

What does "have no reliable initial value" mean when considering the "out"
parameter?

By chance I created a small program as follows:

===========
s : string := "CAT";

procedure modify ( s1 : out string ) is
begin
   s1(2) := 'U';
end modify;

..

put ( modify(s) );
===========

now I get as a result "CUT", and i dont understand why i get this result.
Doesnt the "out" specify that its initial value isnt passed in via the
parameter? But it seems to be passed in the above. In fact the "out" is
acting like an "in out". I am a little confused. Could someone shed some
light on this?

Many thanks!

zork

Re: "out" and "in out"

[David C. Hoos]

"zork" <zork@nospam.com> wrote in message news:4104d5de@dnews.tpgi.com.au...
> Hi i found the following explaination:
>
> In Ada, "in" parameters are similar to C++ const parameters. They are
> effectively read-only within the scope of the called subprogram.
> Ada "in out" parameters have a reliable initial value (that passed
> in from the calling subprogram) and may be modified within the scope
> of the called procedure. Ada "out" parameters have no reliable
> initial value, but are expected to be assigned a value within the
> called procedure.
>
> What does "have no reliable initial value" mean when considering the "out"
> parameter?
It means that wihn the procedure "modify," if youo attempt to read the
value of the formal parameter "s1," it would "have no reliable initial
value."
It has no bearing on the value of the actual parameter "s."
>
> By chance I created a small program as follows:
>
> ===========
> s : string := "CAT";
>
> procedure modify ( s1 : out string ) is
> begin
>    s1(2) := 'U';
> end modify;
>
> ..
>
> put ( modify(s) );
> ===========
>
> now I get as a result "CUT", and i dont understand why i get this result.
> Doesnt the "out" specify that its initial value isnt passed in via the
> parameter? But it seems to be passed in the above. In fact the "out" is
> acting like an "in out". I am a little confused. Could someone shed some
> light on this?
>
> Many thanks!
>
> zork
>
>
>
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada-france.org
> http://www.ada-france.org/mailman/listinfo/comp.lang.ada
>
>

Re: "out" and "in out"

[Martin Krischik]

zork wrote:

> now I get as a result "CUT", and i dont understand why i get this result.
> Doesnt the "out" specify that its initial value isnt passed in via the
> parameter? But it seems to be passed in the above. In fact the "out" is
> acting like an "in out". I am a little confused. Could someone shed some
> light on this?

No it means: Does not *need* to be passed in. However, if using a pointer
instead of the value gives better performance the compiler will do that.
Also there are types which for technical reasons need to be passed using a
pointer.

What you have done comes under "undefined beahavior". If you used:

type s_type is new string (1 .. 3);

s : s_type = "CAT";

procedure modify ( s1 : out s_type) is
begin
ￜￜￜs1(2)ￜ:=ￜ'U';
end modify; 

things *might* be different on standart CPU's since s_type is smaller then
32 bit. BTW: String is indefinite and size therefore undefined. 

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: "out" and "in out"

[Nick Roberts]

On Mon, 26 Jul 2004 19:58:22 +1000, zork <zork@nospam.com> wrote:

> ...
> By chance I created a small program as follows:
>
> ===========
> s : string := "CAT";
>
> procedure modify ( s1 : out string ) is
> begin
>    s1(2) := 'U';
> end modify;
>
> ..
>
> put ( modify(s) );
> ===========
>
> now I get as a result "CUT", and i dont understand why i get
> this result.

> Doesnt the "out" specify that its initial value isnt passed
> in via the parameter?

Yes, but it doesn't forbid the compiler to (effectively) pass
the value in. In practice, this is likely to happen if the
parameter is of a composite type (an array or record), because
the compiler will probably choose to pass it by reference.

> But it seems to be passed in the above. In fact the "out"
> is acting like an "in out".

Yes. This is permitted. But your program would be wrong to
rely upon it.

If you were to try:

===========
n : integer := 456;

procedure modify ( n1 : out integer ) is
begin
    n1 := n1+44;
end modify;

...

modify(n);
put(n);
===========

I think you might not get 500 printed out (I don't, running
this on GNAT 3.15p on Win XP (and GNAT gives a warning)).

-- 
Nick Roberts

Re: "out" and "in out"

[zork]

Thanks for the response everyone. I need to be careful in my implementation.
Some things are obviously not obvious :)

cheers
zork


"Nick Roberts" <nick.roberts@acm.org> wrote in message
news:opsbq1zzd0p4pfvb@bram-2...
> On Mon, 26 Jul 2004 19:58:22 +1000, zork <zork@nospam.com> wrote:
>
> > ...
> > By chance I created a small program as follows:
> >
> > ===========
> > s : string := "CAT";
> >
> > procedure modify ( s1 : out string ) is
> > begin
> >    s1(2) := 'U';
> > end modify;
> >
> > ..
> >
> > put ( modify(s) );
> > ===========
> >
> > now I get as a result "CUT", and i dont understand why i get
> > this result.
>
> > Doesnt the "out" specify that its initial value isnt passed
> > in via the parameter?
>
> Yes, but it doesn't forbid the compiler to (effectively) pass
> the value in. In practice, this is likely to happen if the
> parameter is of a composite type (an array or record), because
> the compiler will probably choose to pass it by reference.
>
> > But it seems to be passed in the above. In fact the "out"
> > is acting like an "in out".
>
> Yes. This is permitted. But your program would be wrong to
> rely upon it.
>
> If you were to try:
>
> ===========
> n : integer := 456;
>
> procedure modify ( n1 : out integer ) is
> begin
>     n1 := n1+44;
> end modify;
>
> ...
>
> modify(n);
> put(n);
> ===========
>
> I think you might not get 500 printed out (I don't, running
> this on GNAT 3.15p on Win XP (and GNAT gives a warning)).
>
> -- 
> Nick Roberts

Re: "out" and "in out"

[Christoph Karl Walter Grein]

"no reliable initial value" means, you cannot rely on the value, but it may have a value. This depends on the parameter passing mechanism, which is _not_ related to the parameter mode (contrary to what many people think).

So the parameter mode is there (nearly) solely for the information of the reader. The parameter passing mechanism for all kinds of parameters is defined in the RM. There are parameters passed by copy (in and out), by reference; for some it is explicitly left undefined.

In your case, the passing mechanism is by reference, so you get what you get. But don't rely on this, rely only on the mode, i.e. the parameter st is undefined upon entering the procedure modify, so when you only write component 2, upon return, only component 2 has been written. Under slight variations, the result of your code might be <garbage character>U<garbage character>.

Another thing: Don't rely upon s1'First = 1. Component 2 might not exist. You could call modify like so:

X: String (25..30);
modify (X);

Now s1(2) inevitably will raise Constraint_Error.
____________________________________________________
Aufnehmen, abschicken, nah sein - So einfach ist 
WEB.DE Video-Mail: http://freemail.web.de/?mc=021200

Re: "out" and "in out"

[Marc A. Criley]

"Christoph Karl Walter Grein" <AdaMagica@web.de> wrote:
>
> In your case, the passing mechanism is by reference, so you get what you
get. But don't rely on this, rely only on the mode, i.e. the parameter st is
undefined upon entering the procedure modify, so when you only write
component 2, upon return, only component 2 has been written. Under slight
variations, the result of your code might be <garbage character>U<garbage
character>.
>
> Another thing: Don't rely upon s1'First = 1. Component 2 might not exist.

While you can't rely on the initial _value_ of the parameter, you _can_ rely
on getting accurate information about it from its attributes.

As Christoph notes, while s1'First may not be 1, s1'First will correctly
reflect the argument's index's first value, similarly for s1'Last and
s1'Length--in this case, 3. And so on for other relevant attributes.

Marc A. Criley
McKae Technologies
www.mckae.com