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

Here's part of the code it does in. Works fairly well:
if($l=~/^\[([^\]]+)\]/) {
   $j=$1; $k=$1;
   $j=$1, $k=$2 if($j=~/^([^\|]+)\|(.+)$/);
            
   $url[$uc]=$j; $l=$k; $op="url$uc"; $uc++;
   print "$op --> $j | $k\n";
            
   $main_index_list->insert("end",$l,$op);
   $main_index_list->tagConfigure($op,-foreground=>"blue", -data=>$j);
   $main_index_list->tagBind($op,"<3>",eval "sub{do_url('$op');}");
}

[download]
Update: Fixed with Merlyn's code.

--
$Stalag99{"URL"}="http://stalag99.keenspace.com";

Replies are listed 'Best First'.
Re: Re: Re: eval with sub
by merlyn (Sage) on Mar 10, 2001 at 02:41 UTC
    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

[reply]
[d/l]
[select]
      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]
        Oh, and BTW, don't worry about Zawinski.

        p
[reply]

In Section Seekers of Perl Wisdom