in reply to (tye)Re3: Finally, a $& compromise!
in thread Finally, a $& compromise!

japhy explains the connection better in Re: Re: Finally, a $& compromise!.

If I understand what he is doing correctly, he is only playing games with deciding whether or not to capture. If you capture, the decision of whether or not to capture $` and $' is separate.

I would like the pragma to be able to decide not just whether or not to capture, but whether or not to copy the whole string. $`/$' are already distinguished from $& in Perl, and separate control would be nice here.

UPDATE
As just discussed in chatter. Using $& is documented in perlre (as of 5.005 and later) as not being as bad as $` and $'. But in my simple test above, it produced the same slowdown. Which indicates a mistake in the documentation...

  • Comment on Re (tilly) 5: Finally, a $& compromise!

Replies are listed 'Best First'.
Re: Re (tilly) 5: Finally, a $& compromise!
by japhy (Canon) on Nov 28, 2001 at 22:31 UTC
    Ok. I think there is a bug with the current Perl right now: 
    #!/usr/bin/perl -l

$_ = "japhy";
1 while /(.)/g;
$_ = "upset";
print $1;  # does this print 'y' or 't' for you?

    [download]
    That code prints "t" for my bleadperl. This means that Perl is not copying the string it matches, but just using a pointer to the string. That explains why this code runs JUST AS FAST as 
    #!/usr/bin/perl -l

$_ = "japhy";
1 while /./g;
$_ = "upset";

    [download]
    Now, this makes the test tilly wrote null and void.

    _____________________________________________________
    Jeff[japhy]Pinyan: Perl, regex, and perl hacker.
    s++=END;++y(;-P)}y js++=;shajsj<++y(p-q)}?print:??;

[reply]
[d/l]
[select]

In Section Meditations