RE: RE: Comparing Arrays

[btrott]

No, that doesn't have the same bug. The bug in the other code was because the join was done on the empty string, which makes the list (3, 5, 7) collapse to "357". When you quote an array, the implicit join is done on the special character $", which by default is a space. So:

    my @a1 = qw/357/;
    my @a2 = qw/3 5 7/;

    print "@a1\n";
    print "@a2\n";

Gives

    357
    3 5 7

Different strings.

You could change $" to be something weirder when doing the comparison; something less likely to be found in a string normally. Like $;:

    sub areq {
        local $" = $;;
        "@{$_[0]}" eq "@{$_[1]}";
    }

[lhoward]

Either way it'll still contain a very similar error. If you pick a "separator" you must guarantee that it won't appear in any of the list element in order to prevent this error. This "string" method can still be shown to perform improperly with certain arrays:

my @a1=('3 5 7');
my @a2=('3','5','7');

[jlistf]

you can avoid this error by performing the test twice, changing the separator between the two tests. i believe (until someone can show me a counter example) that it is impossible to construct two different arrays that will pass this test twice with different separators. ( <--- was that really english? wow was that poorly written. )

jeff

Update: this post was mostly to show how to avoid the error in the stringifying subroutine, but i also did some benchmarking. and... here's what i've found. testing with two separators takes about the same amount of time as looping if the arrays are identical. i don't really know about memory requirements though.

[merlyn]

By that time, you've thrown around so much temporary string space and stringification stuff that you might as well have done the loop.

-- Randal L. Schwartz, Perl hacker