in reply to Re: Passing argument by reference (for a scalar)
in thread Passing argument by reference (for a scalar)

I think, passing a string by reference makes sense when you work with extremely large string

Please read the earlier answers which show this completely wrong. Perl always passes by reference, so there's no reason to pass a reference.

Note that COW has a chance of failing. (The scalar needs to "owned by Perl", and its string buffer must have space to accommodate the COW count.) But even if you want to give your argument names without relying on COW, you don't have to change your code to use references. Instead, you can replace

my $x = shift;

with

use experimental qw( refaliasing declared_refs ); my \$x = \shift;

or

use Data::Alias qw( alias ); alias my $x = shift;

or

our $x; local *x = \shift;

Replies are listed 'Best First'.
Re^3: Passing argument by reference (for a scalar)
by harangzsolt33 (Deacon) on Sep 09, 2024 at 21:12 UTC
    Perl always passes by reference

    Okay, but then why is it that as soon as I do my $STRING = shift; inside my sub, Perl's memory usage doubles (using TinyPerl 5.8 under Windows XP)?

    It seems like it may be passed by reference, but as soon as you grab that using shift() or just do my $MYSTRING = $_[0]; then viola! You have another copy of the string!

      using TinyPerl 5.8 under Windows XP

      Tinyperl is not fully perl: it doesn't even come with Devel::Peek, which has been core since 5.6, before tinyperl 5.8.0 was released. (I found this out when I vainly tried to use your own favorite pseudo-perl to run ikegami's example, and couldn't, because it didn't have that essential part of core.)

      When I use Strawberry Perl 5.8.8 (which comes with all of core), it gets essentially the same results that ikegami already showed: if you use the subroutine's argument directly, rather than making a copy of the string, then Perl doesn't copy the string.

      why is it that as soon as I do my $STRING = shift; inside my sub, Perl's memory usage doubles

      You do realize that you just essentially asked, "why is it that as soon as I make a copy of the string inside my sub, Perl makes a copy of the string?" Do you understand how silly it sounds when rephrased that way?

      Perl 5.8 doesn't have the fancy v5.20 Copy-on-Write ("COW") feature that ikegami mentioned (so the scalar of the copied version doesn't point to the same string buffer), but it does pass the subroutine arguments by reference (so the scalar is the same outside and inside of f($x) ). However, as soon as you make a copy of a string passed by reference, you no longer are using that reference, but a copy of the string -- hence, without COW, the memory goes up when you make the copy , but not when you called the sub . If, like ikegami, you stick to always using the $_[0] rather than creating a copy, it would not double your memory even in tinyperl.

      update: rephrased a few things, but essentially meaning has stayed the same

      update 2: too harsh in some of my wording, especially the struck out -- sorry.

        Perl 5.8 doesn't have the fancy v5.20 Copy-on-Write ("COW") feature that ikegami mentioned (so the scalar of the copied version doesn't point to the same string buffer), but it does pass the subroutine arguments by reference (so the scalar is the same outside and inside of f($x) ). However, as soon as you make a copy of a string passed by reference, you no longer are using that reference, but a copy of the string -- hence, without COW, the memory goes up when you make the copy , but not when you called the sub . If, like ikegami, you stick to always using the $_[0] rather than creating a copy, it would not double your memory even in tinyperl.

        Oh, Okay! I think, I understand it now. Thank you for explaining it at my level. Lol

      Same thing would happen if you did my $STRING = ${ +shift }; if you had passed a reference. If you don't want a copy, don't make a copy! (Also, don't use a 20 year old version of the language!) This was already all covered in detail. Including how what you claim happens hasn't been true for 10 years.

        I'm not familiar with ${ +shift }; syntax. It looks like the + is a way to interpret 'shift' as a command inside ${}. I'm not readily finding documentation for this. Where should I look?