string variable to hold a lengthy string

[John]

I have a rather lengthy string like this:

$page = <<HERE;
<input type="hidden" value="%1">
</form>
....(a couple hundred html lines)
HERE
$page=~s/%1/$myvar/ge;
print $page;


Is there some limit to how long a string the $page variable can hold?
Another question:
The the line
$page=~s/%1/$myvar/ge;
processes the lengthy string. Will I run into some limitations there?
will that cause problems?

 

[Martijn Lievaart]

I have a rather lengthy string like this:

$page = <<HERE;
<input type="hidden" value="%1">
</form>
...(a couple hundred html lines)
HERE $page=~s/%1/$myvar/ge;
print $page;


Is there some limit to how long a string the $page variable can hold?

Limited by available memory. In other words, don't worry about it with
only a few hunderd lines. Start worrying at a few million, but you
probably will be fine even then.

Another question:
The the line $page=~s/%1/$myvar/ge;
processes the lengthy string. Will I run into some limitations there?
will that cause problems?

This should be fine, but why the /e modifier?

Where you can get into problems with regular expressions, is when you
need to backtrack often. In that case, you can get performance problems
with huge strings. But as you have no wildcards in your search pattern,
there is no risk of this.

And even in the case of an inefficient regular expression on a huge
string:
1) with modern fast machines, you probably won't notice anyhow; and
2) you probably need to read and write that string from/to disk/network,
which is relatively slow, so you won't notice anyhow.

HTH,
M4


M4

 

[Rainer Weikusat]

I have a rather lengthy string like this:

$page = <<HERE;
<input type="hidden" value="%1">
</form>
...(a couple hundred html lines)
HERE
$page=~s/%1/$myvar/ge;
print $page;

'A couple of hundred lines' is not 'lengthy' for an at least remotely
modern computer.

Is there some limit to how long a string the $page variable can hold?
Another question:
The the line
$page=~s/%1/$myvar/ge;
processes the lengthy string. Will I run into some limitations there?
will that cause problems?

This roughly amounts to copying the string in sections and inserting
$myvar instead of a %1 from the original string so the answer should
be 'no'. In particular, you won't be able to outperform the C code
which does this substitution copy with anything written in Perl.

 

[John]

Limited by available memory. In other words, don't worry about it with
only a few hunderd lines. Start worrying at a few million, but you
probably will be fine even then.


This should be fine, but why the /e modifier?

I am not sure about it too. Should it be there and if not please elaborate. I
took that from sample code.

 

[Tim McDaniel]

I am not sure about it too. Should it be there and if not please
elaborate. I took that from sample code.

To know what it might be useful for, you can look at the
documentation. In this case, "man perlop", which explains about Perl
operators. A Google search for
"s///e" Perl
turns out not to be bad, which surprises me.

Anyway, from man perlop, I searched for /e. In less, that's
/\/e

I found, in Perl 5.8.8,
s/PATTERN/REPLACEMENT/egimosx

... A "/e" will cause the replacement portion to be treated as a
full-fledged Perl expression and evaluated right then and there.
It is, however, syntax checked at compile-time. A second "e"
modifier will cause the replacement portion to be "eval"ed before
being run as a Perl expression. ...

and explanations of g, i, m, o, s, and x. This is Perl 5.8; r and
maybe other modifiers have been added since.

The example code you provided showed that the string is HTML. Since
the right-hand side of the s/// does not require the full power of
Perl expressions, and since you merely want the variable substituted
in, you do not want to do /e.

The first Google hit is man perlrequick. I find it a little more
helpful:
http://perldoc.perl.org/perlrequick.html

The evaluation modifier s///e wraps an eval{...} around the
replacement string and the evaluated result is substituted for the
matched substring. Some examples:

# reverse all the words in a string
$x = "the cat in the hat";
$x =~ s/(\w+)/reverse $1/ge; # $x contains "eht tac ni eht tah"

# convert percentage to decimal
$x = "A 39% hit rate";
$x =~ s!(\d+)%!$1/100!e; # $x contains "A 0.39 hit rate"

 

[J. Gleixner]

[...]

Looks like the beginning of YATS (Yet Another Template System)

You may want to look at using one of the many Template packages
already available, which will help you design something a little
better by following more of a MVC pattern. You would move those
'couple hundred html lines' out of your program and into another
file (template). Your program itself will be much shorter and
whatever you are doing it will be much easier to maintain/enhance.

http://search.cpan.org/search?query=template&mode=all

http://en.wikipedia.org/wiki/Model–view–controller

 

[Jürgen Exner]

I have a rather lengthy string like this:

$page = <<HERE;
<input type="hidden" value="%1">
</form>
...(a couple hundred html lines)
HERE
$page=~s/%1/$myvar/ge;
print $page;


Is there some limit to how long a string the $page variable can hold?

If I remember correctly from some discussions a long time ago in a
galaxy far away then there is a limit of something like 2GB.
But maybe that was for a 32-bit system, I don't quite remember.

jue

 

[Peter J. Holzer]

I think there used to be an (unnecessary) 2^32 limit, even on 64-bit
systems, but there isn't any more. 5.12 will quite happily create a
string longer than that on a 64-bit system (assuming you've got the
memory to hold it).

Same for 5.10.1 and 5.8.8. Haven't tried older versions.

hp

 

[Rainer Weikusat]

[...]

This roughly amounts to copying the string in sections and inserting
$myvar instead of a %1 from the original string so the answer should
be 'no'.

This obviously implies that my older claim that File::Slurp would
trigger use of an O(n*n) algortihm for 'Windows text file support' is
wrong: It would be true for an in-place substitution performed on the
input string because each individual substitution would require a copy
of the tail string and the total running time would be proportional to
the sum of the lengths of all tail strings which needed to be
copied. But at least for simple substitutions, perl doesn't do that
and while there's theoretically a similar problem with sequences of
copying reallocs, at least for my simple set of test cases and the
realloc implementation of the system I was using, this didn't happen.

OTOH, the 'linearity' of the Perl-level algorithm rests on
undocumented properties of the pp_subst implementation, which, in
turn, relies on undocumented properties of the system realloc, and
this is - in my opinion - extremely bad style and it is also prone to
cause 'maintenance surprises' because Perl will do an in-place
subsitutation in certain cases (read: The code is there and it is not
immediately obvious under which circumstance it is going to be
executed) and it is pretty certain that people won't do an in depth
analysis of this part of the perl implementation before changing a
s/// expression.