=over 10
-=item (?#text)
+=item C<(?#text)>
A comment. The text is ignored. If the C</x> switch is used to enable
whitespace formatting, a simple C<#> will suffice.
-=item (?:regexp)
+=item C<(?:regexp)>
This groups things like "()" but doesn't make backreferences like "()" does. So
but doesn't spit out extra fields.
-=item (?=regexp)
+=item C<(?=regexp)>
A zero-width positive lookahead assertion. For example, C</\w+(?=\t)/>
matches a word followed by a tab, without including the tab in C<$&>.
-=item (?!regexp)
+=item C<(?!regexp)>
A zero-width negative lookahead assertion. For example C</foo(?!bar)/>
matches any occurrence of "foo" that isn't followed by "bar". Note
if (/foo/ && $` =~ /bar$/)
+For lookbehind see below.
-=item (?imsx)
+=item C<(?<=regexp)>
+
+A zero-width positive lookbehind assertion. For example, C</(?=\t)\w+/>
+matches a word following a tab, without including the tab in C<$&>.
+Works only for fixed-width lookbehind.
+
+=item C<(?<!regexp)>
+
+A zero-width negative lookbehind assertion. For example C</(?<!bar)foo/>
+matches any occurrence of "foo" that isn't following "bar".
+Works only for fixed-width lookbehind.
+
+=item C<(?{ code })>
+
+Experimental "evaluate any Perl code" zero-width assertion. Always
+succeeds. C<code> is not interpolated. Currently the rules to
+determine where the C<code> ends are somewhat convoluted.
+
+=item C<(?E<gt>regexp)>
+
+An "independend" subexpression. Matches the substring which a
+I<standalone> C<regexp> would match if anchored at the given position,
+B<and only this substring>.
+
+Say, C<^(?E<gt>a*)ab> will never match, since C<(?E<gt>a*)> (anchored
+at the beginning of string, as above) will match I<all> the characters
+C<a> at the beginning of string, leaving no C<a> for C<ab> to match.
+In contrast, C<a*ab> will match the same as C<a+b>, since the match of
+the subgroup C<a*> is influenced by the following group C<ab> (see
+L<"Backtracking">). In particular, C<a*> inside C<a*ab> will match
+less characters that a standalone C<a*>, since this makes the tail match.
+
+Note that a similar effect to C<(?E<gt>regexp)> may be achieved by
+
+ (?=(regexp))\1
+
+since the lookahead is in I<"logical"> context, thus matches the same
+substring as a standalone C<a+>. The following C<\1> eats the matched
+string, thus making a zero-length assertion into an analogue of
+C<(?>...)>. (The difference of these two constructions is that the
+second one uses a catching group, thus shifts ordinals of
+backreferences in the rest of a regular expression.)
+
+This construction is very useful for optimizations of "eternal"
+matches, since it will not backtrack (see L<"Backtracking">). Say,
+
+ / \( (
+ [^()]+
+ |
+ \( [^()]* \)
+ )+
+ \) /x
+
+will match a nonempty group with matching two-or-less-level-deep
+parentheses. It is very efficient in finding such groups. However,
+if there is no such group, it is going to take forever (on reasonably
+long string), since there are so many different ways to split a long
+string into several substrings (this is essentially what C<(.+)+> is
+doing, and this is a subpattern of the above pattern). Say, on
+C<((()aaaaaaaaaaaaaaaaaa> the above pattern detects no-match in 5sec
+(on kitchentop'96 processor), and each extra letter doubles this time.
+
+However, a tiny modification of this
+
+ / \( (
+ (?> [^()]+ )
+ |
+ \( [^()]* \)
+ )+
+ \) /x
+
+which uses (?>...) matches exactly when the above one does (it is a
+good excercise to check this), but finishes in a fourth of the above
+time on a similar string with 1000000 C<a>s.
+
+Note that on simple groups like the above C<(?> [^()]+ )> a similar
+effect may be achieved by negative lookahead, as in C<[^()]+ (?! [^()] )>.
+This was only 4 times slower on a string with 1000000 C<a>s.
+
+=item C<(?(condition)yes-regexp|no-regexp)>
+
+=item C<(?(condition)yes-regexp)>
+
+Conditional expression. C<(condition)> should be either an integer in
+parentheses (which is valid if the corresponding pair of parentheses
+matched), or lookahead/lookbehind/evaluate zero-width assertion.
+
+Say,
+
+ / ( \( )?
+ [^()]+
+ (?(1) \) )/x
+
+matches a chunk of non-parentheses, possibly included in parentheses
+themselves.
+
+=item C<(?imsx)>
One or more embedded pattern-match modifiers. This is particularly
useful for patterns that are specified in a table somewhere, some of
$pattern = "(?i)foobar";
if ( /$pattern/ )
+Note that these modifiers are localized inside an enclosing group (if
+any). Say,
+
+ ( (?i) blah ) \s+ \1
+
+(assuming C<x> modifier, and no C<i> modifier outside of this group)
+will match a repeated (I<including the case>!) word C<blah> in any
+case.
+
=back
The specific choice of question mark for this and the new minimal
=head2 Backtracking
-A fundamental feature of regular expression matching involves the notion
-called I<backtracking>. which is used (when needed) by all regular
-expression quantifiers, namely C<*>, C<*?>, C<+>, C<+?>, C<{n,m}>, and
-C<{n,m}?>.
+A fundamental feature of regular expression matching involves the
+notion called I<backtracking>. which is currently used (when needed)
+by all regular expression quantifiers, namely C<*>, C<*?>, C<+>,
+C<+?>, C<{n,m}>, and C<{n,m}?>.
For a regular expression to match, the I<entire> regular expression must
match, not just part of it. So if the beginning of a pattern containing a
And if you used C<*>'s instead of limiting it to 0 through 5 matches, then
it would take literally forever--or until you ran out of stack space.
+A powerful tool for optimizing such beasts is "independent" groups,
+which do not backtrace (see L<C<(?E<gt>regexp)>>). Note also that
+zero-length lookahead/lookbehind assertions will not backtrace to make
+the tail match, since they are in "logical" context: only the fact
+whether they match or not is considered relevant. For an example
+where side-effects of a lookahead I<might> have influenced the
+following match, see L<C<(?E<gt>regexp)>>.
+
=head2 Version 8 Regular Expressions
In case you're not familiar with the "regular" Version 8 regexp
projects / p5sagit/p5-mst-13.2.git / blobdiff