reading strings with different lengths

A

ALuPin@web.de

Guest
Hi,

I have the following problem:

In a text file "vectors.txt" the following string is declared:
"640"

When reading the text file with a process I have to declare a string
as follows:


p_ReadFile : process
file F : text open read_mode is "vectors.txt";
variable L : line;
variable resu : string (1 to 5);
begin
readline(F, L);
read(L, resu);
end process p_ReadFile;

Now I want the variable "resu" to store different strings, for example
"640", "1600", "10000".
How do I constraint the string array type so that I can read different
string lengths ?

Thank you for your opinion.

Rgds,
Andre
 
ALuPin@web.de wrote:
Hi,

I have the following problem:

In a text file "vectors.txt" the following string is declared:
"640"

When reading the text file with a process I have to declare a string
as follows:


p_ReadFile : process
file F : text open read_mode is "vectors.txt";
variable L : line;
variable resu : string (1 to 5);
begin
readline(F, L);
read(L, resu);
end process p_ReadFile;

Now I want the variable "resu" to store different strings, for example
"640", "1600", "10000".
How do I constraint the string array type so that I can read different
string lengths ?

Thank you for your opinion.

Rgds,
Andre
Click to expand...
Unfortunately you can't have an unconstrained variable.

If you know that there is a maximum size (for instance 80 characters)
you could do

variable resu : string(1 to 80);
begin
resu := (others => ' '); -- pad with spaces
readline(F,L);
if (L'LENGTH <= resu'LENGTH) then
resu := (others => ' ');
read(L, resu(1 to L'LENGTH));
else
-- error
end if;

Of course then you'll have an 80 character string padded with spaces, so
you might want to write a little function to trim the spaces off.

It also depends what you're going to do with the string. If you don't
need to keep it, you can just return it from a function, e.g.

impure function getString(FILE F : text) return string
variable L : LINE;
begin
readline(F, L);
return L.all;
end;

(I haven't compiled that, I think it's correct...)

regards
Alan

--
Alan Fitch
Doulos
http://www.doulos.com
 
On Sep 25, 1:50 pm, Alan Fitch <alan.fi...@spamtrap.com> wrote:

impure function getString(FILE F : text) return string
variable L : LINE;
begin
readline(F, L);
return L.all;
end;
Click to expand...
A question for Alan (I normally sit opposite him in the office,
but today we're a few hundred miles apart!) and anyone else:
Does this function represent a memory leak? You've populated
variable L with some text, causing it to be allocated, but then
you've returned from the function without deallocating L.
A sufficiently smart compiler could detect that the contents
of L are sure to be unreachable after the function returns,
and then could deallocate it automatically - but is that
mandated by the LRM? I fear not, but I'd be delighted
if someone could reassure me that it's OK.

Explicitly deallocating L in such a function is somewhat
tricky, and is <ahem> left as an exercise for the reader :)
--
Jonathan Bromley
 
spam@oxfordbromley.plus.com a écrit :
On Sep 25, 1:50 pm, Alan Fitch <alan.fi...@spamtrap.com> wrote:

impure function getString(FILE F : text) return string
variable L : LINE;
begin
readline(F, L);
return L.all;
end;

[...]
Does this function represent a memory leak? You've populated
variable L with some text, causing it to be allocated, but then
you've returned from the function without deallocating L.
Click to expand...
I think you're right there.


A sufficiently smart compiler could detect that the contents
of L are sure to be unreachable after the function returns,
and then could deallocate it automatically - but is that
mandated by the LRM? I fear not, but I'd be delighted
if someone could reassure me that it's OK.
Click to expand...
I wouldn't trust the smartness of the compiler. And I don't know the LRM
well enough (must have it somewhere...)


Explicitly deallocating L in such a function is somewhat
tricky, and is <ahem> left as an exercise for the reader :)
Click to expand...
Certainly tricky. I wouldn't try this at home...
As a workaround (or would you call this cheating ?), instead of creating
a function I'd just use "L.all" instead of "read(L, constrainedstring)"

Nicolas
 
spam@oxfordbromley.plus.com wrote:
On Sep 25, 1:50 pm, Alan Fitch <alan.fi...@spamtrap.com> wrote:

impure function getString(FILE F : text) return string
variable L : LINE;
begin
readline(F, L);
return L.all;
end;

A question for Alan (I normally sit opposite him in the office,
but today we're a few hundred miles apart!) and anyone else:
Does this function represent a memory leak? You've populated
variable L with some text, causing it to be allocated, but then
you've returned from the function without deallocating L.
A sufficiently smart compiler could detect that the contents
of L are sure to be unreachable after the function returns,
and then could deallocate it automatically - but is that
mandated by the LRM? I fear not, but I'd be delighted
if someone could reassure me that it's OK.

Explicitly deallocating L in such a function is somewhat
tricky, and is <ahem> left as an exercise for the reader :)
Click to expand...
That occurred to me as I was driving home last night - I think there is
a memory leak as you say. You've just reminded me of that thought :)

I guess as Nicolas says along the thread, why didn't I just suggest
using L.all?

I guess if you did something like

while not (endfile(f)) loop

readline(F, L);
report L.all;
end loop;

wait;


I'd hope there was no memory leak, i.e. the call to readline would
deallocate memory before reading the new line? Is that in the LRM?

regards
Alan


--
Alan Fitch
Doulos
http://www.doulos.com
 
Hi Jonathan

spam@oxfordbromley.plus.com writes:

A sufficiently smart compiler could detect that the contents
of L are sure to be unreachable after the function returns,
and then could deallocate it automatically - but is that
mandated by the LRM?
Click to expand...
Doesn't seem to be mandated but it surely is allowed as far as I can
see. IEEE 1076-2002, 7.3.6 says:

"In the absence of explicit deallocation, an implementation must
guarantee that any object created by the evaluation of an allocator
remains allocated for as long as this object or one of its subelements
is accessible directly or indirectly; that is, as long as it can be
denoted by some name."

Regards
Marcus

--
note that "property" can also be used as syntaxtic sugar to reference
a property, breaking the clean design of verilog; [...]

(seen on http://www.veripool.com/verilog-mode_news.html)
 
Andre,
If you are just reading strings, you can use the built-in
read procedure. Note, the advantage of readline is that
it strips the LF. Also note that neither solution handles
embedded spaces.


TestProc : process
use std.textio.all;
File TestFile : Text ;
variable FileInLine : Line ;
variable FileName : string (1 to 20 ) ;
variable NameLength : natural ;
begin
Write( OUTPUT, "File Name to Read: ");
Read ( INPUT, FileName, NameLength) ;
if (FileName(NameLength) = LF) then
NameLength := NameLength - 1 ;
end if ;
file_open(TestFile, FileName(1 to NameLength), READ_MODE);


Cheers,
Jim


Hi,

I have the following problem:

In a text file "vectors.txt" the following string is declared:
"640"

When reading the text file with a process I have to declare a string
as follows:


p_ReadFile : process
file F : text open read_mode is "vectors.txt";
variable L : line;
variable resu : string (1 to 5);
begin
readline(F, L);
read(L, resu);
end process p_ReadFile;

Now I want the variable "resu" to store different strings, for example
"640", "1600", "10000".
How do I constraint the string array type so that I can read different
string lengths ?

Thank you for your opinion.

Rgds,
Andre
Click to expand...
 
On Sep 26, 11:44 am, Marcus Harnisch <marcus.harni...@gmx.net> wrote:

s...@oxfordbromley.plus.com writes:
A sufficiently smart compiler could detect that the contents
of L are sure to be unreachable after the function returns,
and then could deallocate it automatically - but is that
mandated by the LRM?

Doesn't seem to be mandated but it surely is allowed as far as I can
see. IEEE 1076-2002, 7.3.6 says:

"In the absence of explicit deallocation, an implementation must
guarantee that any object created by the evaluation of an allocator
remains allocated for as long as this object or one of its subelements
is accessible directly or indirectly; that is, as long as it can be
denoted by some name."
Click to expand...
Thanks for doing my LRM dirty work for me :)

The snag is that it's non-trivial for a compiler to determine whether
it's safe to deallocate after an access variable has gone out of
scope.
In Alan's example it is definitely OK, but even then you must do
fairly sophisticated lifetime analysis to prove that not only does
the variable go out of scope, but also there are definitely no
other references to the allocated string. So we have no written
guarantee that the memory occupied by L.all will be reclaimed.

For a string of a few dozen characters, allocated a few hundred
times during a simulation, this obviously doesn't much matter.
But I also like to use access types to give me other kinds of
variable-sized array; suppose I create some megapixel video
fields, and fail to deallocate them? This is an unpleasant
hole in the LRM; I would very much want to do the deallocation
by hand, to be safe.

Thanks
--
Jonathan
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top