for ("ab", "cd") {
  if ($str =~ /$_/) { ... }
}
[download]

($x, $y) = ("ab", "c");
for (1, 2) {
  if ($str =~ /$x$y/) { ... }
  ($x, $y) = ("a", "bc");
}
[download]

1. take regex at this opcode
2. interpolate any variables
3. compare with previous value of the regex at this opcode
4. compile if different
5. execute this regex

So what is qr// good for? Consider this:

my @strings = make_10_strings();
for (@strings) {
  for my $p ('x+', 'yz?y', 'xz+y') {
    if ($_ =~ $p) { handle($_) }
  }
}
[download]

So enter the qr//.

When Perl sees a regex comprised solely of a single variable, Perl checks to see if that variable is a Regexp object (what qr// returns). If it is, Perl knows that the regex has already been compiled, so it simply uses the compiled regex in the place of the regex. That means doing:

my @strings = make_10_strings();
for (@strings) {
  for my $p (qr/x+/, qr/yz?y/, qr/xz+y/) {
    if ($_ =~ $p) { handle($_) }
  }
}
[download]

Be warned that the benefit of qr// objects is lost if there is additional text in the pattern match. I mean that $foo =~ /^$rx_obj$/ suffers from the same problem as $foo =~ /^$text$/.

When Perl sees a regex comprised solely of a single variable, Perl checks to see if that variable is a Regexp object (what qr// returns). If it is, Perl knows that the regex has already been compiled, so it simply uses the compiled regex in the place of the regex.

Really? That is very interesting. So if I have:

my $true  = qr/y(?:es|up)?|1|enabled?/i;
my $false = qr/n(?:o(?:pe)?)?|0|disabled?/i;
die "Need boolean input"
  unless /^(?:$true|$false)$/;
if (/$true/)
{
  do_stuff();
}
[download]

you're saying that in the die's unless clause, it will need to completely recompile the regex? That is not my interpretation, but I could be completely wrong here.

My assumption is that both $true and $false are compiled once, and only once, and the unless modifier above would not need to recompile either one.

Even if that is the case, I use code like the above because I like to be able to reuse a common criteria for truth and falseness across many expressions - sometimes, as in the die statement above, for validation that the value is something (i.e., not a typo - if someone had "y]", we'd not accidentally treat that as a false value, we'd simply reject it so the user could fix the typo), or, at other times, such as the if statement above, just to see which one it was. Which goes to the OP's question on why it's useful, somewhat in agreement with other posts here. I'm just showing a concrete example of real, live, production code where I use this construct.

It won't need to recompile the entire regex each time, because $true and $false haven't changed, but Perl will need to compare the string representation of the regex with the representation of it the last time it was at this opcode. And the first time through, yes, it will compile the regex.
_____________________________________________________
Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Hi, I was just refactoring some code and saw a possible opportunity to use this advice. But. Instead of having multiple strings in @strings to process, I leave all the lines from my file joined together as one giant string with embedded \n chars. From this angle, since I only have to use each regex once across all the strings via them being 'joined' into one string, I won't benefit from qr.

    my ( $crummy, $good );
    foreach my $crummy_good_ar ( @corrections_to_make ) {
        ( $crummy, $good ) = @$crummy_good_ar;
        $file_in_string_form =~ s/\b(\Q$crummy\E)\b/$good/ig;
    }
[download]

However, as you can see (?) from the example above, I have lots of crummy/good switchouts to do, and is my plodding approach above the best that can be expected?

P.S. Can you clarify/update what you meant by:
the benefit of qr// objects is lost if there is additional text in the pattern match

I think you are saying that a precompiled/qr regex used in a follow-on regex will have to be recompiled if you snap additional text on to the qr'd variable, because the overall text of the new regex will be different. Although at least one would still have the benefit of 'concentrated regex logic' within the qr'd variable?

I can answers your first question by answering your second one. If you made all the first elements of your array references Regexp objects:

$_->[0] = qr/\b(\Q$_->[0]\E)b/ for @corrections_to_make;
[download]

then you could do your loop as

for my $crummy_good_ar (@corrections_to_make) {
  my ($crummy, $good) = @$crummy_good_ar;
  $file_in_string_form =~ s/$crummy/$good/ig;
}
[download]

This way, even if you end up looping over THAT code, you'd still be dealing with already-compiled regexes. As soon as you put additional text into a regex with qr// in it:

my $rx = qr/abc/;
if ($str =~ /^($rx)$/) { ... }
[download]

Perl has to do the "compare physical regex forms" test. Only if the qr// object is all alone will it have the entire benefits it was made for.

---

Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Here's an example from a code-filtering assertions module (yes, another one) that's not yet tested thoroughly enough to submit to CPAN: