Re: Disabling regexp optimizations?

I haven't dipped my toe into this deeper end of the regex pool yet, so I'm curious about the motivation behind your question. If I understand it right, you want an expression, which you are placing within (?{...}), to execute every time you evaluate this regex, regardless of whether or not the remainder of the regex yields an actual match.

If that is the correct understanding, why would you want to do it that way, as opposed to this way:

   your_executable_expression;
   /XXX/
[download]

That is, since this expression should execute in any case, just go ahead and do it outside the regex, then evaluate the (simpler) regex.

If I have the wrong understanding, could someone explain what you get from /(?{...}).../ (without the optimization, as requested here) that you wouldn't get from running that statement outside the regex? (I just don't know.)

Comment on Re: Disabling regexp optimizations? Select or Download Code

Replies are listed 'Best First'.
Re^2: Disabling regexp optimizations? by diotalevi (Canon) on Oct 15, 2005 at 18:52 UTC
The code in (?{...}) might have a desired side effect. Usually you use (?{...}) blocks only for their side effects because they don't normally impact whether the expression matches. In my case, I've implemented named captures and would like to pre-clear the targets just in case my capture expressions never get evaluated because something earlier failed. That is, CLEAR->stuff->CAPTURE. If "stuff" failed, then I wouldn't have had the opportunity to ensure that CAPTURE properly cleared the selected target.	[reply]
Re^3: Disabling regexp optimizations? by bart (Canon) on Oct 16, 2005 at 00:31 UTC
I like your idea, but... It is not how (anonymous) captures in Perl work, do they? I mean, nothing is guaranteed about the value of $1, $2 etc. in a regexp with captures, if the regexp doesn't match.	[reply]
Re^4: Disabling regexp optimizations? by diotalevi (Canon) on Oct 17, 2005 at 02:26 UTC
Of late, I'm not sure that's so true. The most recent perls (the last year anyway) ensures that all potentially used capture variables are cleared regardless of whether the expression succeeds. So /((...)\|(...))/ addresses $1, $2, and $3. Since the fix, you can guarantee that each variable will have a sane value. You still can't guarantee $4 -> on though. I think. Or could those be guaranteed already?	[reply]