a little help

a little help

[F]

Hello world,
          i'm trying to learn Ada but i've a lot of problems with the
operations with strings.
In particular i've a procedure for the input:

type st is new string;
procedure leggis (j: in out st) is
       c:character;

    begin
           while not end_of_line loop
        get(c); b(ind):=c; ind:=ind+1;
           end loop;
    end leggis;


when i call the first time this procedure i obtain the input string but the
second time nothing happens.....
I think that character return remains in the keyboard buffer, how can I
resolve this problem?????

Excuse me for the scarce clarity of my english.......
Thank you!  :-))

Re: a little help

[Gerhard Häring]

On Tue, 16 Oct 2001 10:39:14 +0200, F <phosphorus@libero.it> wrote:
>Hello world,
>          i'm trying to learn Ada but i've a lot of problems with the
>operations with strings.
>In particular i've a procedure for the input:
>
>type st is new string;
>procedure leggis (j: in out st) is
>    c:character;
>begin
>    while not end_of_line loop
>        get(c); b(ind):=c; ind:=ind+1;
>    end loop;
>end leggis;
>
>
>when i call the first time this procedure i obtain the input string but the
>second time nothing happens.....
>I think that character return remains in the keyboard buffer, how can I
>resolve this problem?????

Looks like you're not telling us the whole story. Where do the b and ind
variables come from? Looks like they *should* be put in the procedure
but they're now declared and initialized outside in (global?) variables.
This means you get so-called side-effects when running the procedure:
the procedure isn't self-contained but changes state elsewhere. This
usually leads to bugs sooner or later.

Solution: put all variables into the proecedure and initialize them
there, too. ind should be initialized to 0 if I see this correctly.

If you want to improve the code even further, you can make the j
parameter "out" instead of "in out", but even better would be to make
the whole thing a function instead.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: a little help

[F]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]


Thank you for your help but i've modified the procedure (now ind is an
in-side variable and the parameter j is in out) and there are still the same
problems.
The problem is the second recall of my procedure.
Please help me................. :-)


P.S.
I send you the entire new program

procedure prova is
    type st is new string;
    b:st(1..20);
     ind:integer:=1;

    procedure leggis (j: in out st; i: in out integer) is
       c:character;

    begin

           while not end_of_line loop
        get(c); j(ind):=c; i:=i+1;
           end loop;
    end leggis;


begin
    new_line;
    leggis(b,ind);
    for i in 1..ind loop
        put(b(i));
    end loop;
    ind:=1;
    new_line;
--this is the beginning of my problems!!
        leggis(b,ind);
     for i in 1..15 loop
        put(b(i));
     end loop;
    end prova;



Gerhard H�ring ha scritto nel messaggio ...
>On Tue, 16 Oct 2001 10:39:14 +0200, F <phosphorus@libero.it> wrote:
>>Hello world,
>>          i'm trying to learn Ada but i've a lot of problems with the
>>operations with strings.
>>In particular i've a procedure for the input:
>>
>>type st is new string;
>>procedure leggis (j: in out st) is
>>    c:character;
>>begin
>>    while not end_of_line loop
>>        get(c); b(ind):=c; ind:=ind+1;
>>    end loop;
>>end leggis;
>>
>>
>>when i call the first time this procedure i obtain the input string but
the
>>second time nothing happens.....
>>I think that character return remains in the keyboard buffer, how can I
>>resolve this problem?????
>
>Looks like you're not telling us the whole story. Where do the b and ind
>variables come from? Looks like they *should* be put in the procedure
>but they're now declared and initialized outside in (global?) variables.
>This means you get so-called side-effects when running the procedure:
>the procedure isn't self-contained but changes state elsewhere. This
>usually leads to bugs sooner or later.
>
>Solution: put all variables into the proecedure and initialize them
>there, too. ind should be initialized to 0 if I see this correctly.
>
>If you want to improve the code even further, you can make the j
>parameter "out" instead of "in out", but even better would be to make
>the whole thing a function instead.
>
>Gerhard
>--
>mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
>web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
>public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
>reduce(lambda x,y:x+y,map(lambda
x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: a little help

[Ted Dennison]

In article <9qgrgh$1f10$1@newsreader1.mclink.it>, F says...
>type st is new string;
>        get(c); b(ind):=c; ind:=ind+1;
>
>when i call the first time this procedure i obtain the input string but the
>second time nothing happens.....
>I think that character return remains in the keyboard buffer, how can I
>resolve this problem?????

Since this looks like a school assignment, I'll give out a hint only. If "get"
isn't working for you, it would seem sensible to try a different routine, no?
Look through the package Get comes from and see if you can find anything else
useful in there.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.

Re: a little help

[Martin Dowie]

> If you want to improve the code even further, you can make the j
> parameter "out" instead of "in out", but even better would be to make
> the whole thing a function instead.

Not necessarily, returning composite typed objects from functions
can lead to some nasty run-time inefficiencies.

Re: a little help

[Gerhard Häring]

On Tue, 16 Oct 2001 14:23:58 +0200, F <phosphorus@libero.it> wrote:
>in-side variable and the parameter j is in out) and there are still the same
>problems.
>The problem is the second recall of my procedure.
>Please help me................. :-)
>
>
>P.S.
>I send you the entire new program
>
>procedure prova is
>    type st is new string;
>    b:st(1..20);
>    ind:integer:=1;
>
>    procedure leggis (j: in out st; i: in out integer) is
>       c:character;
>    begin
>        while not end_of_line loop
>            get(c); j(ind):=c; i:=i+1;
>        end loop;
>    end leggis;
>
>begin
>    new_line;
>    leggis(b,ind);
>    for i in 1..ind loop
>        put(b(i));
>    end loop;
>    ind:=1;
>    new_line;
>    -- this is the beginning of my problems!!
>    leggis(b,ind);
>    for i in 1..15 loop
>        put(b(i));
>    end loop;
>end prova;

You're still using global variables. Don't. These are almost always
causes of errors. If you need variables in your main procedure, declare
them in a declare block like

declare
    ind := integer := 1;
begin
    -- main procedure logic here
end prova;

I don't want to entirely debug your program (it could be written much
simpler with using the appropriate stuff from Ada.Text_IO and perhaps
Ada.Strings.(Un)bounded). But now the global variables are causing the
bugs. You should avoid them whenever you can.

Gerhard
-- 
mail:   gerhard <at> bigfoot <dot> de       registered Linux user #64239
web:    http://www.cs.fhm.edu/~ifw00065/    OpenPGP public key id 86AB43C0
public key fingerprint: DEC1 1D02 5743 1159 CD20  A4B6 7B22 6575 86AB 43C0
reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))

Re: a little help

[F]

Dear Ted,
              i understand that this problem seems a school homework but i'm
not a student....
I'm trying to learn this language alone and i've not a great number of
manuals to read....
If i wrote this message is because i think that someone could help me.
Consider that i'm a graduate in Matematics and so i'm not so expert on a
programming
language.
I hope you would reconsider your answer an send me a way to understand my
problem whith Ada....
Thank you
Phosphorus

Ted Dennison ha scritto nel messaggio ...
>In article <9qgrgh$1f10$1@newsreader1.mclink.it>, F says...
>>type st is new string;
>>        get(c); b(ind):=c; ind:=ind+1;
>>
>>when i call the first time this procedure i obtain the input string but
the
>>second time nothing happens.....
>>I think that character return remains in the keyboard buffer, how can I
>>resolve this problem?????
>
>Since this looks like a school assignment, I'll give out a hint only. If
"get"
>isn't working for you, it would seem sensible to try a different routine,
no?
>Look through the package Get comes from and see if you can find anything
else
>useful in there.
>
>---
>T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
>
>No trees were killed in the sending of this message.
>However a large number of electrons were terribly inconvenienced.

Re: a little help

[Preben Randhol]

On Tue, 16 Oct 2001 10:39:14 +0200, F wrote:
> Hello world,
>           i'm trying to learn Ada but i've a lot of problems with the
> operations with strings.

Here are some links that may be useful:

Ada Craft on-line book on Ada 95: 
http://www.it.bton.ac.uk/staff/je/adacraft/ 

Object Oriented Programming in Ada 95
http://burks.bton.ac.uk/burks/language/ada/ada95.pdf

The Big Online Book of Linux Ada Programming
http://www.vaxxine.com/pegasoft/homes/book.html

Preben Randhol

Re: a little help

[Ted Dennison]

In article <9qjaos$1q80$1@newsreader1.mclink.it>, F says...
>              i understand that this problem seems a school homework but i'm
>not a student....

In that case, I'll drop the hints and tell you that "Get" is almost never used
for reading keyboard input. Try using Get_Line instead.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html

No trees were killed in the sending of this message. 
However a large number of electrons were terribly inconvenienced.