in reply to associative array problem

As noted in chatter, you should be using CGI, and your code could use some refactoring.

However the source of the problem would be caught by strict.pm. The problem is that you are assigning into slot 1 the string 'mname', and then you are proceeding to access it as if it was an array. (Note, you are using brackets, and not braces.) Perl tries to figure out what you mean by that, and guesses that you want to access the global array @mname. So you overwrite the same array each time and wind up with grief.

My immediate suggestion is that you use strict.pm and study references quick reference. And then be sure to use CGI.

  • Comment on Re (tilly) 1: associative array problem

Replies are listed 'Best First'.
Re: Re (tilly) 1: associative array problem
by CharlesClarkson (Curate) on Nov 02, 2001 at 23:04 UTC

    To clarify that a bit, the program can be reduced to:

    my %STUDQT;
$STUDQT{11} =  [qw/fname mname/];
$STUDQT{11}[1][2] =  0;
#$STUDQT{12} =  [qw/fname mname/];
$STUDQT{12}[1][2] =  0;

print
    qq|\$STUDQT{11}[1][2] = $STUDQT{11}[1][2]\n|,
    qq|\t\$STUDQT{12}[1][2] = $STUDQT{12}[1][2]\n|;
$STUDQT{11}[1][2] = 'hello'; #Problem
print
    qq|\$STUDQT{11}[1][2] = $STUDQT{11}[1][2]\n|,
    qq|\t\$STUDQT{12}[1][2] = $STUDQT{12}[1][2]\n|;

__END__

    [download]
    Don't use strict and run it as is:
    $STUDQT{11}[1][2] = 0
    $STUDQT{12}[1][2] = 0
$STUDQT{11}[1][2] = hello
    $STUDQT{12}[1][2] = 0

    [download]
    Just as we expect. But uncomment: #$STUDQT{12} =  [qw/fname mname/]; and we get: 
    $STUDQT{11}[1][2] = 0
    $STUDQT{12}[1][2] = 0
$STUDQT{11}[1][2] = hello
    $STUDQT{12}[1][2] = hello

    [download]

    Turning on strict reveals that we are attempting to use 'mname' as a symbolic reference and perl guesses what we are attempting as tilly mentioned.

    HTH,
    Charles K. Clarkson

[reply]
[d/l]
[select]
Re: Re (tilly) 1: associative array problem
by Gerryjun (Scribe) on Nov 02, 2001 at 20:36 UTC
    It is an array a multidimensional array at that, the script is from a much more complex script it is just a simulation of the problem. So instead of getting the values from STDIN ex. 

    read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
        ($names, $value) = split(/=/, $pair);
        $value =~ tr/+/ /;
        $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
        if ($INPUT{$names}) { $INPUT{$names} = $INPUT{$names}.",".$val
+ue; }
        else { $INPUT{$names} = $value; }
}

    [download]
    I have assigned it directly to array! & Instead of including the file and accessing it and load it in an array using loops I just directly given its values for the sake of the simulation.

    I don?t understand what you mean my CGI? But if its on the extension its the same!
[reply]
[d/l]
      You are parsing your CGI input directly, and doing it in a broken way. What I was talking about is using the standard CGI module to parse your input for you, more flexibly, meeting the whole standard, without security holes, with support for file uploads, with support for command line debugging, etc, etc, etc. Read use CGI or die; for details on what people typically get wrong (yes, you made the typical mistakes), and for simple examples of how to use the module.

      As for the problem you complained about, I already told you why you have the behaviour you do, and how to automatically catch the error that leads to it. And what I meant by saying that you're using an array instead of a hash is that you are using strings like '01' as indexes into an array. I strongly recommend either making that a hash, or just using numbers. As it stands your choice of index and data structure are passing conflicting messages. Experienced programmers see conflicts like that and label them as mistakes. What kind of mistake may not be obvious, but they are mistakes.

      UPDATE
      BTW you may find it better to just use a nested hash. For instance if you just assign your values like: 

      $STUDQT{'32000012'}{mname}[1] = 0;

      [download]
      without initializing $STUDQT{'32000012'}{mname}, Perl will no longer misbehave on you. (Of course strict.pm is still strongly recommended to catch other incidences of the same mistake. Catching bugs early is a Good Thing.)
[reply]
[d/l]

In Section Seekers of Perl Wisdom