in reply to Re^4: Common Perl Pitfalls
in thread Common Perl Pitfalls
For starters, I happen to believe it's better for readability.
more readable than
$pat = qr/PAT/;
$pat = q/PAT/;
If so, what is it that makes it more readable? Of course, readability is a subjective matter.
$pat = 'PAT';
Another thing is, the regex modifiers "come with it". So you can include things like the 'x' modifier right along with the regex;
$pat = '(?x:foo bar)'; # Works fine
if you're using a string as a regex, on the other hand, you have to remember which modifiers you need when you finally decide to use it in a match.
I don't know what you mean by that.
Also, even though it doesn't show in this example, qr// is more efficient as (IIRC) it pre-compiles its regex before matching: i.e. you can build the regex once and use it several times.
That's only useful if you want to use exactly the same pattern in different lines of your program.
I use the qr// operator this way to make my regexes "modular".
That's exactly why I don't use qr much.
In the above code snippet, Perl only has to compile a single regexp. Contrast:
my $pat1 = 'PAT1';
my $pat2 = 'PAT2';
$str =~ /$pat1$pat2/;
Now Perl has to compile three patterns, and stringify two of them. I've created programs that created large patterns from qr constructs that were dog slow, because the final pattern was huge (stringifying qr constructs adds more parens, and adds (?abc-def:)) -- replacing qr with q sped up the program significantly. (Perl has gotten better since, yet, building larger patterns from smaller ones using qr snippets is still less efficient than using q).
my $pat1 = qr/PAT1/;
my $pat2 = qr/PAT2/;
$str =~ /$PAT1$PAT2/;
I'm here to learn...
Writing a meditation titled Common Perl Pitfalls suggests otherwise.