Re: Parse

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on Tue, 21 Jan 2003
22:19:46 -0500


> Speaking of parse... working with it on large files with large-ish
> variables (say 200 bytes) seems to run into memory errors. I'm thinking of
> avoiding parse, but maybe I'm doing something wrong. Have others found
> parse less than robust?

No. 100% reliable, if the source $tring and the input separator (S/Gs 01 and
02 below) are good.

> When parse is re-used, as in a loop, I normally null out the s/gs before
> re-parsing, and I'm not sure if that is necessary.

> E.g.,
> ;*;
> ;*; the nulling out--unnecessary? a good idea?
> ;*;
> >;*; the re-assignment, to parse the tail after looping
> ;*;

You only need to null out the prospective results if 1) the result S/Gs already
are initialized and have content going into the parse, and 2) there's a chance
that the parse itself will bomb, e.g. if S/G 01 is empty -- in that case, you
could emerge on the far side of the parse with erroneous results in 03 and 05.
I sometimes null out from an excess of caution, for example when I know in
advance that S/G 03 or 05 will be empty on exit (because the separator matches
either the first or last part of the source $tring) -- occasionally the
pre-existing content of 03 or 05 will survive the parse operation. Or e.g.
when the parse is in a SUbroutine that might exit prematurely (pre-parse) for
some other reason. Your example above should at least be checking that S/G 05
has content ( greater than 0) before rewinding. Lest anyone else be
confused, it's probably worth noting that the fragmentary routine above does
absolutely nothing, and would eventually crash (endless loop).

Good question.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------