reading strings with different lengths

[ALuPin]

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]

Hi Alan,

thank you for your solution !

Rgds

 

[Guest]

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

 

[Nicolas Matringe]

(e-mail address removed) a écrit :

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.

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.

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

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

 

[Marcus Harnisch]

Hi Jonathan

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

Regards
Marcus

 

[Guest]

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

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