hashref strange side effects

Discussion in 'Perl Misc' started by penguinista, Dec 23, 2004.

  1. penguinista

    penguinista Guest

    # load a map into memory
    sub readmap
    { my ($map, $file) = @_; # $map is a hashref here
    my ($line, $type, $name);
    return if eof $file;
    $line = <$file>;
    chomp $line;
    if ($line =~ /\{\s*(\w+)\s+(\w+)/)
    { $type = $1; $name = $2;
    if (!defined($map->{$name}))
    { $map->{$name} = {'parent'=>$map, 'name'=>$name, 'type'=>$type}; }
    &readmap($map->{$name}, $file);
    }
    elsif ( $line =~ /(\w+)=(.+)/ )
    { $map->{$1} = $2; # this sets field value, then shoots off to garbage
    }
    elsif ($line =~ /\}/)
    { return; }
    else {}; # error
    }

    It the above subroutine, the line $map->{$1} = $2 assigns key+value into
    the hash as expected, then shoots off to a sub DESTROY {} in package
    IO::Handle; before returning to my code after the call to the subroutine
    that first calls recursive routine readmap. $1 = 'val', $2 = '"Login"'

    running perl 5.8.5 in cygwin.

    any ideas?
     
    penguinista, Dec 23, 2004
    #1
    1. Advertising

  2. penguinista

    penguinista Guest

    penguinista wrote:

    > # load a map into memory
    > sub readmap
    > { my ($map, $file) = @_; # $map is a hashref here
    > my ($line, $type, $name);
    > return if eof $file;
    > $line = <$file>;
    > chomp $line;
    > if ($line =~ /\{\s*(\w+)\s+(\w+)/)
    > { $type = $1; $name = $2;
    > if (!defined($map->{$name}))
    > { $map->{$name} = {'parent'=>$map, 'name'=>$name, 'type'=>$type}; }
    > &readmap($map->{$name}, $file);
    > }
    > elsif ( $line =~ /(\w+)=(.+)/ )
    > { $map->{$1} = $2; # this sets field value, then shoots off to garbage
    > }
    > elsif ($line =~ /\}/)
    > { return; }
    > else {}; # error
    > }
    >
    > It the above subroutine, the line $map->{$1} = $2 assigns key+value into
    > the hash as expected, then shoots off to a sub DESTROY {} in package
    > IO::Handle; before returning to my code after the call to the subroutine
    > that first calls recursive routine readmap. $1 = 'val', $2 = '"Login"'
    >
    > running perl 5.8.5 in cygwin.
    >
    > any ideas?


    Looks like I forgot the itteration loop. still doesn't quite explain
    the debugger results.
     
    penguinista, Dec 23, 2004
    #2
    1. Advertising

  3. penguinista

    Anno Siegel Guest

    penguinista <> wrote in comp.lang.perl.misc:
    > # load a map into memory
    > sub readmap
    > { my ($map, $file) = @_; # $map is a hashref here
    > my ($line, $type, $name);
    > return if eof $file;
    > $line = <$file>;
    > chomp $line;
    > if ($line =~ /\{\s*(\w+)\s+(\w+)/)
    > { $type = $1; $name = $2;
    > if (!defined($map->{$name}))
    > { $map->{$name} = {'parent'=>$map, 'name'=>$name, 'type'=>$type}; }
    > &readmap($map->{$name}, $file);
    > }
    > elsif ( $line =~ /(\w+)=(.+)/ )
    > { $map->{$1} = $2; # this sets field value, then shoots off to garbage
    > }
    > elsif ($line =~ /\}/)
    > { return; }
    > else {}; # error
    > }
    >
    > It the above subroutine, the line $map->{$1} = $2 assigns key+value into
    > the hash as expected, then shoots off to a sub DESTROY {} in package
    > IO::Handle; before returning to my code after the call to the subroutine
    > that first calls recursive routine readmap. $1 = 'val', $2 = '"Login"'
    >
    > running perl 5.8.5 in cygwin.
    >
    > any ideas?


    Presumably the file handle in $file goes out of scope on return from
    that call. The line you mention just happens to be the last line
    executed in the sub. There's nothing mysterious about it. Why is
    it bothering you?

    Anno
     
    Anno Siegel, Dec 23, 2004
    #3
  4. penguinista

    penguinista Guest

    Anno Siegel wrote:

    > penguinista <> wrote in comp.lang.perl.misc:
    >
    >># load a map into memory
    >>sub readmap
    >>{ my ($map, $file) = @_; # $map is a hashref here
    >> my ($line, $type, $name);
    >> return if eof $file;
    >> $line = <$file>;
    >> chomp $line;
    >> if ($line =~ /\{\s*(\w+)\s+(\w+)/)
    >> { $type = $1; $name = $2;
    >> if (!defined($map->{$name}))
    >> { $map->{$name} = {'parent'=>$map, 'name'=>$name, 'type'=>$type}; }
    >> &readmap($map->{$name}, $file);
    >> }
    >> elsif ( $line =~ /(\w+)=(.+)/ )
    >> { $map->{$1} = $2; # this sets field value, then shoots off to garbage
    >> }
    >> elsif ($line =~ /\}/)
    >> { return; }
    >> else {}; # error
    >>}
    >>
    >>It the above subroutine, the line $map->{$1} = $2 assigns key+value into
    >>the hash as expected, then shoots off to a sub DESTROY {} in package
    >>IO::Handle; before returning to my code after the call to the subroutine
    >>that first calls recursive routine readmap. $1 = 'val', $2 = '"Login"'
    >>
    >>running perl 5.8.5 in cygwin.
    >>
    >>any ideas?

    >
    >
    > Presumably the file handle in $file goes out of scope on return from
    > that call. The line you mention just happens to be the last line
    > executed in the sub. There's nothing mysterious about it. Why is
    > it bothering you?
    >
    > Anno


    I'm used to the debugger showing the return from subroutine. I guess
    it's a C vs. perl in debugger thing.
     
    penguinista, Dec 24, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jim Bancroft
    Replies:
    2
    Views:
    2,450
    =?Utf-8?B?UmFodWwgQW5hbmQ=?=
    Dec 28, 2004
  2. Avdi B. Grimm
    Replies:
    0
    Views:
    103
    Avdi B. Grimm
    Oct 5, 2005
  3. bill

    Equality of hashref objects

    bill, Feb 4, 2005, in forum: Perl Misc
    Replies:
    7
    Views:
    148
    Anno Siegel
    Feb 5, 2005
  4. Sam
    Replies:
    6
    Views:
    176
    Anno Siegel
    Jun 15, 2005
  5. Sam
    Replies:
    1
    Views:
    96
    Ron Savage
    Aug 25, 2005
Loading...

Share This Page