Re: Strings and reading from a file

Re: Strings and reading from a file

[David Botton]

Take a look at the package Ada.Strings.Unbounded in the RM A.4.5

David Botton


Cameron Hodge wrote:
> 
> Hey guys and girls
> 
> I know this is pretty simple but I have to read some strings in from a file.
> I have declared the type to be
> 
> Firstname : String of length 1..20
> 
> I can read the string in fine, no probs there, but if the string is under
> the 20 characters I get rubbish in the remaining string positions. Now I got
> around this by assigning firstname := " <20 spaces>" however when I now
> display this string to the screen, it displayes the full 20 characters. How
> to do I remove the training Space's ????
> 
> Now I know I get the length of the string when I read it in and can declare
> the varialle there and then, but I am reading in many strings all of
> different lengths into an array.
> 
> hmm I hope everyone can understand this.
> 
> Thanks
> 
> vampyre@ozemail.com.au

Strings and reading from a file

[Cameron Hodge]

Hey guys and girls

I know this is pretty simple but I have to read some strings in from a file.
I have declared the type to be

Firstname : String of length 1..20

I can read the string in fine, no probs there, but if the string is under
the 20 characters I get rubbish in the remaining string positions. Now I got
around this by assigning firstname := " <20 spaces>" however when I now
display this string to the screen, it displayes the full 20 characters. How
to do I remove the training Space's ????



Now I know I get the length of the string when I read it in and can declare
the varialle there and then, but I am reading in many strings all of
different lengths into an array.

hmm I hope everyone can understand this.

Thanks

vampyre@ozemail.com.au

Re: Strings and reading from a file

[Robert Dewar]

In article <7han2q$jkp$1@news.iinet.net.au>,
  "Cameron Hodge" <vampyre@ozemail.com.au> wrote:
> Now I know I get the length of the string when I read it in
and can declare
> the varialle there and then, but I am reading in many strings
all of
> different lengths into an array.

So, keep track of these lengths! Simple enough logic to do that.
Or use one of the built-in string packages in the RM.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Strings and reading from a file

[dennison]

In article <7hbnnl$rca$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-dejanews.com> wrote:
> In article <7han2q$jkp$1@news.iinet.net.au>,
>   "Cameron Hodge" <vampyre@ozemail.com.au> wrote:
> > Now I know I get the length of the string when I read it in
> and can declare
> > the varialle there and then, but I am reading in many strings
> all of
> > different lengths into an array.
>
> So, keep track of these lengths! Simple enough logic to do that.

In case you don't understand how this helps, you should know that you
can pass just *part* of a string (or any array for that matter) to a
subroutine. Assume your 20 character string is named "My_String" and you
have its length stored in "My_String_End":

Ada.Text_IO.Put_Line ( My_String(1..My_String_End) );



--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Strings and reading from a file

[Cameron Hodge]

True enough. I was just hoping not to have to create another array.



Robert Dewar <robert_dewar@my-dejanews.com> wrote in message
news:7hbnnl$rca$1@nnrp1.deja.com...
> In article <7han2q$jkp$1@news.iinet.net.au>,
>   "Cameron Hodge" <vampyre@ozemail.com.au> wrote:
> > Now I know I get the length of the string when I read it in
> and can declare
> > the varialle there and then, but I am reading in many strings
> all of
> > different lengths into an array.
>
> So, keep track of these lengths! Simple enough logic to do that.
> Or use one of the built-in string packages in the RM.
>
>
> --== Sent via Deja.com http://www.deja.com/ ==--
> ---Share what you know. Learn what you don't.---

Re: Strings and reading from a file

[Marin David Condic]

Cameron Hodge wrote:
> 
> True enough. I was just hoping not to have to create another array.
> 
You may be missing the point. Look at the packages in appendix A.4 of
the ARM. Specifically, I'd recommend Ada.Strings.Unbounded in A.4.5. You
have a type called Unbounded_String. You also have a function: "Length"
that operates on Unbounded_String. Also functions To_Unbounded_String
and To_String will be useful to you here. If you have an array of
Unbounded_String, you can store whatever strings you read in and their
lengths will be remembered.

As you're reading in strings, you get the length as one of the returned
parameters. You can "slice" the string to be just that length - thus
removing anything that is garbage. The trick is to write yourself a
function that returns a value of type String. Internally, it declares
some sufficiently large String variable to handle a worst case, but it
only returns the slice. (The space is recovered off the stack when the
function returns, so it isn't wasted.) Do something like:

function Next_Line return String is
    Str  : String (1..256) ;
    Len  : Natural ;
begin
    Get_Line (
        Item  => Str,
        Last  => Len) ;
    return Str (1..Len) ;
end Next_Line ;

You can dress up the function to make it look as pretty as you like -
maybe even make it a general-purpose utility by adding a file parameter,
etc. Somewhere between this and the features you have in
Ada.Strings.Unbounded you can do whatever you like with flexible sized
strings and you won't have to fuss with leftover garbage, unused space
or anything else inconvenient. Of course, the price you pay for the
convenience may be some additional execution speed or memory
utilization, but unless you are working on something with a real time
sensitivity, this should not be much of a concern.

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: Strings and reading from a file

[Gautier]

A simple solution (among others):
- to read:  Get_Line(s,l)
- to use:   s(1..l)
- to write: Put(s(1..l)) or Put_Line(s(1..l))
with l natural.

-- 
Gautier

--------
http://members.xoom.com/gdemont/

Re: Strings and reading from a file

[Tom Moran]

>you get the length as one of the returned
>parameters
Actually, you get the last index, which is numerically equal to the
length in the particular case that the first index is 1.  It's a
dangerous habit to start assuming Last = Length.

Re: Strings and reading from a file

[David C. Hoos, Sr.]

Cameron Hodge wrote in message <7hc358$ha5$1@news.iinet.net.au>...
>True enough. I was just hoping not to have to create another array.
>
Instead of creating two arrays -- you could make a record for each string,
having two components:
   1. the string (1 .. 20), or whatever
   2. The last index written into the string.

Incidentally, strictly speaking you do not get directly the length of the
string you read from the file -- you get the _last index_ of your string
into which a character was read from the file.

For example, sometimes one might read into a slice of a string -- i.e.,
not starting at index 1 -- or for whatever other reason read into a string
whose 'First attribute /= 1.

Re: Strings and reading from a file

[Marin David Condic]

Tom Moran wrote:
> 
> >you get the length as one of the returned
> >parameters
> Actually, you get the last index, which is numerically equal to the
> length in the particular case that the first index is 1.  It's a
> dangerous habit to start assuming Last = Length.

Quite right and maybe I should be more careful when using examples such
as this when the unknown feature being explained is the issue. I'd
rather assume that an experienced Ada programmer writing a "general
purpose" string handling routine would know enough not to do that, yet
get away with it in instances that are as nicely isolated as my little
example. (I guess I get sloppy with definitions because by nature I hate
to sweat the details! :-)

Of course, if the string had been defined as, say, String (301..556),
then we'd be looking at "Last" not representing the "Length" of the
string, but of the last used cell of the array. So let the student
beware when listening to my advice!

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: Strings and reading from a file

[jrcarter001]

In article <37399913.BD928DD1@pwfl.com>,
  diespammer@pwfl.com wrote:

...

> function Next_Line return String is
>     Str  : String (1..256) ;
>     Len  : Natural ;
> begin
>     Get_Line (
>         Item  => Str,
>         Last  => Len) ;
>     return Str (1..Len) ;
> end Next_Line ;

...

Make the function recursive, and it can return a string of any length,
eliminating that nagging worry about strings that are longer than
whatever magic number you used in the function.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Strings and reading from a file

[dennison]

In article <7hevh1$g08$1@nnrp1.deja.com>,
  jrcarter001@my-dejanews.com wrote:
> In article <37399913.BD928DD1@pwfl.com>,
>   diespammer@pwfl.com wrote:
>
> ...
>
> > function Next_Line return String is
> >     Str  : String (1..256) ;
> >     Len  : Natural ;
> > begin
> >     Get_Line (
> >         Item  => Str,
> >         Last  => Len) ;
> >     return Str (1..Len) ;
> > end Next_Line ;
>
> ...
>
> Make the function recursive, and it can return a string of any length,
> eliminating that nagging worry about strings that are longer than
> whatever magic number you used in the function.

Surely you don't mean (forgive me if Deja decides to throw away my
formatting):

function Next_Line return String is
   Char : Character;
   Next_Char : Character;
   EOL  : Boolean;
begin
   Get (Char);
   Look_Ahead (Next_Char, EOL);
   if EOL then
      return (1 => Char);
   else
      return Char & Next_Line;
   end if;
end Next_Line;

I think we may have just smoked out a Lisp programmer...

--
T.E.D.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Strings and reading from a file

[Martin C. Carlisle]

I can't imagine!  Probably something more like:

function Next_Line(File : in Ada.Text_IO.File_Type := 
   Ada.Text_Io.Standard_Input) return String is
   Answer : String(1..256);
   Last   : Natural;
begin
   Ada.Text_IO.Get_Line(File => File,
      Item => Answer,
      Last => Last);
   if Last = Answer'Last then
      return Answer & Next_Line;
   else
      return Answer(1..Last);
   end if;
end Next_Line;

--Martin

In article <7hf2bc$imm$1@nnrp1.deja.com>,  <dennison@telepath.com> wrote:
>In article <7hevh1$g08$1@nnrp1.deja.com>,
>> Make the function recursive, and it can return a string of any length,
>> eliminating that nagging worry about strings that are longer than
>> whatever magic number you used in the function.
>
>Surely you don't mean (forgive me if Deja decides to throw away my
>formatting):
>
>function Next_Line return String is
>   Char : Character;
>   Next_Char : Character;
>   EOL  : Boolean;
>begin
>   Get (Char);
>   Look_Ahead (Next_Char, EOL);
>   if EOL then
>      return (1 => Char);
>   else
>      return Char & Next_Line;
>   end if;
>end Next_Line;
>
>I think we may have just smoked out a Lisp programmer...
>
>--
>T.E.D.
>
>
>--== Sent via Deja.com http://www.deja.com/ ==--
>---Share what you know. Learn what you don't.---


-- 
Martin C. Carlisle, Asst Prof of Computer Science, US Air Force Academy
carlislem@acm.org, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standards or 
policy of the US Air Force Academy or the United States Government.

Re: Strings and reading from a file

[Marin David Condic]

Martin C. Carlisle wrote:
> 
> I can't imagine!  Probably something more like:
> 
> function Next_Line(File : in Ada.Text_IO.File_Type :=
>    Ada.Text_Io.Standard_Input) return String is
>    Answer : String(1..256);
>    Last   : Natural;
> begin
>    Ada.Text_IO.Get_Line(File => File,
>       Item => Answer,
>       Last => Last);
>    if Last = Answer'Last then
>       return Answer & Next_Line;
>    else
>       return Answer(1..Last);
>    end if;
> end Next_Line;
> 
This is a very clever and much more general solution than my original
code segment. (I must confess, I've seen this idiom before.) It has the
decided advantage that it will work for any length line and coupled with
the Unbounded_String type makes the most "polished" answer to the
original post. (If Cameron Hodge is still listening?) Obviously, it will
not incur any recursion overhead for most lines, so it has efficiency
working for it as well.

However - enamoured as I am with the "perfect" solution that works for
any case that may arise - I'd wonder if in practice it isn't a bit of
overkill. In my experience with text files, most lines are less than the
80 character width of a punchcard or glass-teletype. Probably 95% of
text lines are within twice that number. I can't recall ever seeing a
text line (in a standard text file like what would be used for some word
processing app - not a custom data file) which ever exceeded a 256 byte
string. 

Perhaps I'll have to dig up my newly minted statistics library and hack
together a little program to produce the descriptive statistics on line
length from some collection of text files - just so I know what length
to pick to get me to Six Sigma on the "defect rate"? Or would that
constitute proof that I have way too much time on my hands? (Well at
least its not as bad as the web page where someone translated the King
James Version of the Bible into Pig Latin! :-)

MDC
-- 
Marin David Condic
Real Time & Embedded Systems, Propulsion Systems Analysis
United Technologies, Pratt & Whitney, Large Military Engines
M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600
***To reply, remove "bogon" from the domain name.***

Visit my web page at: http://www.flipag.net/mcondic

Re: Strings and reading from a file

[Keith Thompson]

Marin David Condic <condicma@bogon.pwfl.com> writes:
[...]
> However - enamoured as I am with the "perfect" solution that works for
> any case that may arise - I'd wonder if in practice it isn't a bit of
> overkill. In my experience with text files, most lines are less than the
> 80 character width of a punchcard or glass-teletype. Probably 95% of
> text lines are within twice that number. I can't recall ever seeing a
> text line (in a standard text file like what would be used for some word
> processing app - not a custom data file) which ever exceeded a 256 byte
> string. 

No, it's not overkill.  I commonly work with text files containing
lines hundreds, or even thousands, of characters long.  Most of them
are machine-generated (log files and such).

If you're writing something that will have to deal with arbitrary text
files as input, make sure it will handle arbitrarily long lines.  Even
if you can guarantee (or enforce) that your input lines will never be
longer than some fixed limit, make sure your code fails gracefully if
that limit is exceeded.  Truncation may be acceptable; random
misbehavior is not.

One advantage of Ada is that, even if you don't specifically think to
handle long input lines, you're not likely to step on memory if you
receive unexpected input.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.

Re: Strings and reading from a file

[Hyman Rosen]

Marin David Condic <condicma@bogon.pwfl.com> writes:
> However - enamoured as I am with the "perfect" solution that works for
> any case that may arise - I'd wonder if in practice it isn't a bit of
> overkill.

No, it's not. One of the most annoying things about the old, pre-GNU
UNIX utilities were the plethora of built-in line limitations they
had. It is in the exceptional situations where you most need your
tools working properly. If the tools silently discard lines which
are too long, or divide them into several lines, or crash, or die
with an exception, that's a very bad thing.

For example, my .newsrc file, which is a plain text file, has some
very long lines in it. I have a little awk script which finds the
widest line in a file. On Solaris, nawk aborts with

	nawk: input record `comp.lang.c++! 63853...' too long

On Linux, everything runs fine, and I discover that the longest line,
for comp.lang.c++, is 27530 characters long!

If you find yourself fighting the language in order to handle input of
arbitrary size, then it's a problem of the language. I know that it's
not much of an issue in C++, and I would guess it's not much of an
issue in Ada either. Limiting input to the size of a fixed buffer is
just laziness or incompetence.

Re: Strings and reading from a file

[David Botton]

May I include your code on The Ada Source Code Treasury at AdaPower.com?

David Botton


"Martin C. Carlisle" wrote:
> 
> I can't imagine!  Probably something more like:
> 
> function Next_Line(File : in Ada.Text_IO.File_Type :=
>    Ada.Text_Io.Standard_Input) return String is
>    Answer : String(1..256);
>    Last   : Natural;
> begin
>    Ada.Text_IO.Get_Line(File => File,
>       Item => Answer,
>       Last => Last);
>    if Last = Answer'Last then
>       return Answer & Next_Line;
>    else
>       return Answer(1..Last);
>    end if;
> end Next_Line;
> 
> --Martin
> 
> In article <7hf2bc$imm$1@nnrp1.deja.com>,  <dennison@telepath.com> wrote:
> >In article <7hevh1$g08$1@nnrp1.deja.com>,
> >> Make the function recursive, and it can return a string of any length,
> >> eliminating that nagging worry about strings that are longer than
> >> whatever magic number you used in the function.
> >
> >Surely you don't mean (forgive me if Deja decides to throw away my
> >formatting):
> >
> >function Next_Line return String is
> >   Char : Character;
> >   Next_Char : Character;
> >   EOL  : Boolean;
> >begin
> >   Get (Char);
> >   Look_Ahead (Next_Char, EOL);
> >   if EOL then
> >      return (1 => Char);
> >   else
> >      return Char & Next_Line;
> >   end if;
> >end Next_Line;
> >
> >I think we may have just smoked out a Lisp programmer...
> >
> >--
> >T.E.D.
> >
> >
> >--== Sent via Deja.com http://www.deja.com/ ==--
> >---Share what you know. Learn what you don't.---
> 
> --
> Martin C. Carlisle, Asst Prof of Computer Science, US Air Force Academy
> carlislem@acm.org, http://www.usafa.af.mil/dfcs/bios/carlisle.html
> DISCLAIMER:  This content in no way reflects the opinions, standards or
> policy of the US Air Force Academy or the United States Government.

Re: Strings and reading from a file

[David Botton]

Sorry, I hit the wrong key.

David Botton wrote:
> 
> May I include your code on The Ada Source Code Treasury at AdaPower.com?
> 
> David Botton

Re: Strings and reading from a file

[David C. Hoos, Sr.]

Keith Thompson wrote in message ...
>"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
>[...]
>> While were at improving it, what about:
>> function Next_Line
>>   (File : in Ada.Text_IO.File_Type :=  Ada.Text_Io.Standard_Input;
>>    Guessed_Length : Positive := 256) return String is
>[...]
>
>Shouldn't the default for File be Ada.Text_IO.Current_Input rather
>than Ada.Text_IO.Standard_Input?  (Not that I've ever understood the
>need for the distinction, but we might as well be consistent.)
>
Current_Input is switchable from file to file by a running program,
whereas Standard_Input is fixed from the program's perspective.

Re: Strings and reading from a file

[Pascal Obry]

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


Keith Thompson <kst@cts.com> a �crit dans le message :
yecr9ok4rpn.fsf@king.cts.com...
> Marin David Condic <condicma@bogon.pwfl.com> writes:
> [...]
> > However - enamoured as I am with the "perfect" solution that works for
> > any case that may arise - I'd wonder if in practice it isn't a bit of
> > overkill. In my experience with text files, most lines are less than the
> > 80 character width of a punchcard or glass-teletype. Probably 95% of
> > text lines are within twice that number. I can't recall ever seeing a
> > text line (in a standard text file like what would be used for some word
> > processing app - not a custom data file) which ever exceeded a 256 byte
> > string.
>
> No, it's not overkill.  I commonly work with text files containing
> lines hundreds, or even thousands, of characters long.  Most of them
> are machine-generated (log files and such).
>

Sure others cases are Web pages. Some generator do not add CR in the
HTML file. So a Web page turn out to be written on one line... I've seen
some
line (well page :-) that are more than 10kb long!

Pascal.

Re: Strings and reading from a file

[Jean-Pierre Rosen]

David Botton a �crit dans le message <373B93FC.9E89E2C2@Botton.com>...
>May I include your code on The Ada Source Code Treasury at
AdaPower.com?
>
>David Botton
>
>
>"Martin C. Carlisle" wrote:
>>
>> I can't imagine!  Probably something more like:
>>
>> function Next_Line(File : in Ada.Text_IO.File_Type :=
>>    Ada.Text_Io.Standard_Input) return String is
>>    Answer : String(1..256);
>>    Last   : Natural;
>> begin
>>    Ada.Text_IO.Get_Line(File => File,
>>       Item => Answer,
>>       Last => Last);
>>    if Last = Answer'Last then
>>       return Answer & Next_Line;
>>    else
>>       return Answer(1..Last);
>>    end if;
>> end Next_Line;
>>
While were at improving it, what about:
function Next_Line
  (File : in Ada.Text_IO.File_Type :=  Ada.Text_Io.Standard_Input;
   Guessed_Length : Positive := 256) return String is
   Answer : String(1..Guessed_Length);
   Last   : Natural;
begin
   Ada.Text_IO.Get_Line(File => File,
      Item => Answer,
      Last => Last);
   if Last = Answer'Last then
      return Answer & Next_Line (File, 2*Guessed_Length);
   else
      return Answer(1..Last);
   end if;
end Next_Line;

This will minimize the number of recursive calls for very long lines.
(Not also that in the previous version, the recursive call to
Next_Line forgot the File argument).
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Strings and reading from a file

[Keith Thompson]

"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
[...]
> While were at improving it, what about:
> function Next_Line
>   (File : in Ada.Text_IO.File_Type :=  Ada.Text_Io.Standard_Input;
>    Guessed_Length : Positive := 256) return String is
[...]

Shouldn't the default for File be Ada.Text_IO.Current_Input rather
than Ada.Text_IO.Standard_Input?  (Not that I've ever understood the
need for the distinction, but we might as well be consistent.)

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.

Re: Strings and reading from a file

[Keith Thompson]

I wrote:
> > Shouldn't the default for File be Ada.Text_IO.Current_Input rather
> > than Ada.Text_IO.Standard_Input?  (Not that I've ever understood the
> > need for the distinction, but we might as well be consistent.)

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> replied:
> Current_Input is switchable from file to file by a running program,
> whereas Standard_Input is fixed from the program's perspective.

I know what it does, but I question the wisdom of having it in the
standard.  I don't think I've ever seen a call to Set_Input or
Set_Output outside a test program.

Yes, it can be handy to have a quick and dirty way to redirect default
input and output within a program, but I'd much rather use another
File_Type object or parameter than mess around with the global state
of Ada.Text_IO.  After all, that's why there are versions of Put_Line,
Get_Line, etc. that take File_Type parameters.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
Techno-geek.  Mouse bigger than phone.  Bites heads off virtual chickens.

Re: Strings and reading from a file

[David C. Hoos, Sr.]

Keith Thompson <kst@cts.com> wrote in message
news:yecyairi5mm.fsf@king.cts.com...
> I wrote:
> > > Shouldn't the default for File be Ada.Text_IO.Current_Input rather
> > > than Ada.Text_IO.Standard_Input?  (Not that I've ever understood the
> > > need for the distinction, but we might as well be consistent.)
>
> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> replied:
> > Current_Input is switchable from file to file by a running program,
> > whereas Standard_Input is fixed from the program's perspective.
>
> I know what it does, but I question the wisdom of having it in the
> standard.  I don't think I've ever seen a call to Set_Input or
> Set_Output outside a test program.
>
> Yes, it can be handy to have a quick and dirty way to redirect default
> input and output within a program, but I'd much rather use another
> File_Type object or parameter than mess around with the global state
> of Ada.Text_IO.  After all, that's why there are versions of Put_Line,
> Get_Line, etc. that take File_Type parameters.
>
Well, I saw it used quite a lot one  program, and it brought to light
that there was an error in the compiler vendor's implementation of
Text_IO;
We made a fix to the implementation, and submitted it to the vendor,
who rejected our solution because of some AI (I don't remember the number).

After four years of waiting, I gave up on the vendor ever fixing it.
I'm no longer on that program, but I think they're still using my
"workaround."

Re: Strings and reading from a file

[jrcarter001]

In article <7hf611$16i$1@cnn.Princeton.EDU>,
  mcc@entropy.cs.princeton.edu (Martin C. Carlisle) wrote:
> I can't imagine!  Probably something more like:
>
> function Next_Line(File : in Ada.Text_IO.File_Type :=
>    Ada.Text_Io.Standard_Input) return String is
>    Answer : String(1..256);
>    Last   : Natural;
> begin
>    Ada.Text_IO.Get_Line(File => File,
>       Item => Answer,
>       Last => Last);
>    if Last = Answer'Last then
>       return Answer & Next_Line;
>    else
>       return Answer(1..Last);
>    end if;
> end Next_Line;
>
> --Martin
>
> In article <7hf2bc$imm$1@nnrp1.deja.com>,  <dennison@telepath.com>
wrote:
> >In article <7hevh1$g08$1@nnrp1.deja.com>,
> >> Make the function recursive, and it can return a string of any
length,
> >> eliminating that nagging worry about strings that are longer than
> >> whatever magic number you used in the function.
> >
> >Surely you don't mean (forgive me if Deja decides to throw away my
> >formatting):
> >
> >function Next_Line return String is
> >   Char : Character;
> >   Next_Char : Character;
> >   EOL  : Boolean;
> >begin
> >   Get (Char);
> >   Look_Ahead (Next_Char, EOL);
> >   if EOL then
> >      return (1 => Char);
> >   else
> >      return Char & Next_Line;
> >   end if;
> >end Next_Line;
> >
> >I think we may have just smoked out a Lisp programmer...

I didn't expect to generate such a response...

The original inspiration for this is

Carter, J., "Variable-Length String Input in Ada", _Ada Letters_, 1989
May/Jun

which presents the following (Ada-83) algorithm:

with Text_Io;
function Get_Line (File : Text_Io.File_Type := Text_Io.Current_Input)
return String is
   Char : Character;
begin -- Get_Line
   if Text_Io.End_Of_Line (File) then
      Text_Io.Skip_Line (File);

      return "";
   else
      Text_Io.Get (File, Char);

      return Char & Get_Line (File);
   end if;
end Get_Line;

This is the output of a straightforward algorithm creation process,
which goes something like:

In Ada, it has to be a function so the result can be any length. Ok,
assume I have a function that will return the rest of the line, provided
I get the first character myself. Use that function to implement itself:

begin
   Text_Io.Get (Char);

   return Char & Get_Line;
end;

How do I terminate the recursion? When I'm at the end of the line. What
do I return then? A null string. End of exercise, and the function is
finished, and works correctly. Pretty it up by adding a File parameter
with appropriate default, and you're done.

However, most lines are short, and recursion for every character seems
wasteful, even though it ran as fast as I could want. My current
implementation has improved the algorithm:

with Ada.Text_Io;
use Ada;
function Get_Line (File : Text_Io.File_Type := Text_Io.Current_Input)
return String is
   Line : String (1 .. 100);
   Last : Natural;
begin -- Get_Line
   Text_IO.Get_Line (File => File, Item => Line, Last => Last);

   if Last < Line'Last then
      return Line (Line'First .. Last);
   else
      return Line & Get_Line (File);
   end if;
end Get_Line;

This is effectively the same as Carlisle's  version. This does no
recursion for most lines I've encountered, and gracefully handles the
"pathological" cases. It still has trouble with those lines
that are Positive'Last characters long, especially on 32-bit machines.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

Re: Strings and reading from a file

[Jean-Pierre Rosen]

Keith Thompson a �crit dans le message ...
>"Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> writes:
>[...]
>> While were at improving it, what about:
>> function Next_Line
>>   (File : in Ada.Text_IO.File_Type :=  Ada.Text_Io.Standard_Input;
>>    Guessed_Length : Positive := 256) return String is
>[...]
>
>Shouldn't the default for File be Ada.Text_IO.Current_Input rather
>than Ada.Text_IO.Standard_Input?  (Not that I've ever understood the
>need for the distinction, but we might as well be consistent.)
>
Sure... but that's the part of the specification I did NOT change ;-)
---------------------------------------------------------
           J-P. Rosen (Rosen.Adalog@wanadoo.fr)
Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Strings and reading from a file

[Matthew Heaney]

jrcarter001@my-dejanews.com writes:

> It still has trouble with those lines that are Positive'Last
> characters long, especially on 32-bit machines.

Why?