comp.lang.ada
 help / color / mirror / Atom feed
From: Marin David Condic <condicma@bogon.pwfl.com>
Subject: Re: Strings and reading from a file
Date: 1999/05/12
Date: 1999-05-12T00:00:00+00:00	[thread overview]
Message-ID: <37399913.BD928DD1@pwfl.com> (raw)
In-Reply-To: 7hc358$ha5$1@news.iinet.net.au

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




  reply	other threads:[~1999-05-12  0:00 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-05-12  0:00 Strings and reading from a file Cameron Hodge
1999-05-11  0:00 ` David Botton
1999-05-12  0:00 ` Robert Dewar
1999-05-12  0:00   ` dennison
1999-05-12  0:00   ` Cameron Hodge
1999-05-12  0:00     ` Marin David Condic [this message]
1999-05-12  0:00       ` Tom Moran
1999-05-12  0:00         ` Marin David Condic
1999-05-13  0:00       ` jrcarter001
1999-05-13  0:00         ` dennison
1999-05-13  0:00           ` Martin C. Carlisle
1999-05-13  0:00             ` David Botton
1999-05-13  0:00               ` David Botton
1999-05-14  0:00               ` Jean-Pierre Rosen
1999-05-14  0:00                 ` Keith Thompson
1999-05-14  0:00                   ` David C. Hoos, Sr.
1999-05-14  0:00                     ` Keith Thompson
1999-05-15  0:00                       ` David C. Hoos, Sr.
1999-05-16  0:00                   ` Jean-Pierre Rosen
1999-05-13  0:00             ` Marin David Condic
1999-05-13  0:00               ` Hyman Rosen
1999-05-13  0:00               ` Keith Thompson
1999-05-14  0:00                 ` Pascal Obry
1999-05-15  0:00             ` jrcarter001
1999-06-05  0:00               ` Matthew Heaney
1999-05-12  0:00     ` David C. Hoos, Sr.
1999-05-12  0:00 ` Gautier
replies disabled

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