comp.lang.ada
 help / color / mirror / Atom feed
* "out" and  "in out"
@ 2004-07-26  9:58 zork
  2004-07-26 11:00 ` David C. Hoos
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: zork @ 2004-07-26  9:58 UTC (permalink / raw)


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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: "out" and  "in out"
@ 2004-07-26 10:54 Christoph Karl Walter Grein
  2004-07-26 14:16 ` Marc A. Criley
  0 siblings, 1 reply; 7+ messages in thread
From: Christoph Karl Walter Grein @ 2004-07-26 10:54 UTC (permalink / raw)
  To: comp.lang.ada

"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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: "out" and  "in out"
  2004-07-26  9:58 zork
@ 2004-07-26 11:00 ` David C. Hoos
  2004-07-26 11:30 ` Martin Krischik
  2004-07-26 14:46 ` Nick Roberts
  2 siblings, 0 replies; 7+ messages in thread
From: David C. Hoos @ 2004-07-26 11:00 UTC (permalink / raw)



"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
>
>




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: "out" and  "in out"
  2004-07-26  9:58 zork
  2004-07-26 11:00 ` David C. Hoos
@ 2004-07-26 11:30 ` Martin Krischik
  2004-07-26 14:46 ` Nick Roberts
  2 siblings, 0 replies; 7+ messages in thread
From: Martin Krischik @ 2004-07-26 11:30 UTC (permalink / raw)


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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: "out" and  "in out"
  2004-07-26 10:54 "out" and "in out" Christoph Karl Walter Grein
@ 2004-07-26 14:16 ` Marc A. Criley
  0 siblings, 0 replies; 7+ messages in thread
From: Marc A. Criley @ 2004-07-26 14:16 UTC (permalink / raw)


"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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: "out" and  "in out"
  2004-07-26  9:58 zork
  2004-07-26 11:00 ` David C. Hoos
  2004-07-26 11:30 ` Martin Krischik
@ 2004-07-26 14:46 ` Nick Roberts
  2004-07-28 14:07   ` zork
  2 siblings, 1 reply; 7+ messages in thread
From: Nick Roberts @ 2004-07-26 14:46 UTC (permalink / raw)


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



^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: "out" and  "in out"
  2004-07-26 14:46 ` Nick Roberts
@ 2004-07-28 14:07   ` zork
  0 siblings, 0 replies; 7+ messages in thread
From: zork @ 2004-07-28 14:07 UTC (permalink / raw)


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





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2004-07-28 14:07 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-07-26 10:54 "out" and "in out" Christoph Karl Walter Grein
2004-07-26 14:16 ` Marc A. Criley
  -- strict thread matches above, loose matches on Subject: below --
2004-07-26  9:58 zork
2004-07-26 11:00 ` David C. Hoos
2004-07-26 11:30 ` Martin Krischik
2004-07-26 14:46 ` Nick Roberts
2004-07-28 14:07   ` zork

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox