Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re: my $cache = undef if undef;

by Aristotle (Chancellor)
on Jan 26, 2005 at 17:14 UTC ( #425289=note: print w/replies, xml ) Need Help??

in reply to my $cache = undef if undef;

Sorry to all the previous commenters, but they're all wrong. Tanktalus is close with his second bullet point, but then he says it doesn't work, which is wrong.

That piece of code makes a pseudostatic variable, ie one that persists across calls to the function.

This is known as the my $foo if 0 trick. The if undef in your code is the same thing painted green: a false condition.

This shouldn't be used in production code. Tanktalus' suggestion of using a closed-off scope is what you should replace it with.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: my $cache = undef if undef;
by borisz (Canon) on Jan 26, 2005 at 18:33 UTC
    Thanks, for that nice and surprising explanation. Looks like the dark side of perl.
Re^2: my $cache = undef if undef;
by Tanktalus (Canon) on Jan 26, 2005 at 17:38 UTC

    Thanks for the update/correction ... although saying that I'm wrong is merely semantics. The URL you point to leaves me with the impression that Larry is implying that this could change in the future - whether that is within Perl5 (as the implication at the time could have been) or Perl6, is left open. Given that, I would suggest that any statement implying that this code "works" is misleading. It happens to work with a current version of perl, but is open to breakage under newer versions of perl (including PONIE), with Larry not sounding too concerned about it.

    I'm somewhat curious if intervening memory usage could clobber this trick - e.g., calling IsMatrix early, then using 200MB of memory, then coming back and calling IsMatrix a second time. Or does this trick make Perl think it's static (closed-off scope with lexical references in a global sub), thus leaking memory where, without the if 0, it would not be a memory leak? (I realise that "memory leak" is debatable here.)

      No, that's not how Perl manages memory. I've dug into this code lately, so here's a slightly fuller explanation that only has a few oversimplifications (as far as I know).

      When Perl compiles a subroutine, it attaches a couple of arrays to the subroutine. These are lexical pads. The first array holds several other arrays. The first contained array holds the names of all lexical variables. The second contained array holds the values of all lexical variables. (I believe subsequent contained arrays hold values on recursion, but I haven't dug that deeply.)

      The compile-time effect of my is to create an entry in the pad, storing the appropriate name in the first contained array and making a space in the second contained array for the value of that lexical variable.

      The run-time effect of an assignment to a lexical variable is to store the appropriate value in the second contained array. If there's a conditional, though, that assignment won't happen.

      For reasons of optimization, I believe that Perl doesn't reset all elements in the contained arrays to undef when it leaves a subroutine. Thus if your assignment doesn't happen due to a false conditional, you could see an old value persist through invocations.

      As far as I know, the memory won't change location; if you use up megabytes of heap memory elsewhere, there should be no effect on the lexical pads unless you exhaust all real and virtual memory and then you have bigger problems.

      It cannot be clobbered, and there are no memory leaks in either case. It's an effect of how the pads for lexical variables are maintained by the Perl core. Larry didn't want to promise this will always work, but it's very unlikely to break, since it's kind of an accidental feature of the Perl guts architecture. A lot would have to change to break it.

      Makeshifts last the longest.

        It may very well be gone someday in perl5. Really. Don't use it. Also note that the staticness is relative to the pad, not the function; for instance, the data does not persist for recursive calls to the function.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://425289]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (12)
As of 2017-02-22 15:59 GMT
Find Nodes?
    Voting Booth?
    Before electricity was invented, what was the Electric Eel called?

    Results (331 votes). Check out past polls.