in reply to Re: Re: eval with sub
in thread eval with sub

No. Stop with that eval. You are re-compiling that code every time you call that. There's no need. 
$main_index_list->tagBind($op, "<3>", do { my $thing = $op; sub { do_u
+rl($thing) } });

[download]
That'll be faster, safer, won't leak memory like a sieve, and if you had made $op a lexical variable earlier, could have been just written as : 
$main_index_list->tagBind($op, "<3>", sub { do_url($op) });

[download]
But since I don't know the scope of $op, I wrote it safely.

Please eliminate the runtime string-eval there! Please. It's so very unneeded.

-- Randal L. Schwartz, Perl hacker

Replies are listed 'Best First'.
Re: Re: Re: Re: eval with sub
by sierrathedog04 (Hermit) on Mar 10, 2001 at 12:41 UTC
    Merlyn wrote "That'll be faster, safer, won't leak memory like a sieve"

    Is Merlyn saying that poorly coded Perl can leak memory?

    According to the Memory Advisor page "A leak is a data area that your program allocated but did not free, even though your program will not use the memory again. In many instances, the data area has no pointer..."

    I thought that Perl takes care of such matters automatically, and that memory leaks were not a problem in Perl programs. Now I think from the comments of Merlyn and others that memory leaks can indeed be a problem in Perl.

    For instance, Jamie Zawinski wrote in a 1998 article that

    just about all of the open source garbage collectors are junk (e.g., Perl, Python, and Emacs.) Perl's GC is an especially bad joke: if you have circular references, the objects won't get collected until the program exits! Give me a break!

    Do poorly-coded Perl programs really contain memory leaks?

[reply]
      A Perl program can indeed leak memory if you accidentally (or intentionally!) set up circular references. Perl uses a "reference counting" scheme for tracking objects. Objects are reclaimed (garbage collected) when their reference count goes to zero. If you set up a pair of objects to reference each other, their reference counts will never go to zero, even after the variables that originally pointed to them have gone out of scope.

      There's a bit more discussion of the in perlman:perltoot.

[reply]
        And besides that, there's also apparently a leak in the compiler, so repeated compilation continues to leak. I think it shows up particularly if the compiler has to abort in the middle, and less so if the compiler completes its task on a compilation unit.

        Hence, repeated runtime string-eval is bad. Don't do it.

        -- Randal L. Schwartz, Perl hacker

[reply]
        The perl manuals state that:

        "The only situation where Perl's reference-based GC won't work is when there's a circularity in the data structure, such as:
        $this->{WHATEVER} = $this;"
        One can easily imagine such a self-reference. For instance, an object-oriented tax program might include a reference to one's employer. If one is self-employed then a self-reference could result.

        It is still not immediately clear why Merlyn says that using eval in the situation he describes also creates a memory leak. I guess that the lesson for new monks in this thread is to avoid eval when it can be avoided, since it can have unknown deleterious effects on memory management.

[reply]
      Oh, and BTW, don't worry about Zawinski.

      p
[reply]

In Section Seekers of Perl Wisdom