my @keys   = qw/a    b    c/;
my @values = qw/foo bar baz/;

my %h;
@h{ @keys } = @values;
## or . . .
@h{ qw/ a b c/ } = qw/foo bar baz/;
[download]

The only klunky thing is that you can't initialize a slice and declare the hash with my in one swell foop; gotta do it as two separate statements. See perldata for more on hash slices.

There's a zip in List::MoreUtils that you can use.

use List::MoreUtils 'zip';

@keys   = qw/a    b    c/;
@values = qw/foo bar baz/;

my %h = zip @keys, @values;
[download]

use List::MoreUtils qw(zip);
[download]

use Data::Dumper;

sub zip {
  my @list1 = @{shift()};
  my @list2 = @{shift()};
  my @zip;
  while (@list1+@list2) {
    push(@zip, shift(@list1), shift(@list2));
  }
  @zip
}

my @z1 = zip([qw(a b c)], [qw(5 6 7 8 9)]);
print Dumper(\@z1);
my @z2 = zip([qw(5 6 7 8 9)], [qw(d e f)]);
print Dumper(\@z2);
[download]

Ew. Copying both arrays to avoid destroying them is horribly inefficient. As is building an array only to return it as a list:

sub zip {
    my( $r1, $r2 ) = @_;
    map {
        $r1->[ $_ ], $r2->[ $_ ]
    } 0 .. ( @$r1 > @$r2 ? @$r1 : @$r2 );
}
[download]

Updated length determination.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Nice, but the zip function you postedappends two undefs onto the end of the result set. Use $# to get last indexes.

my @a = 1..3;
my @b = qw( a b c );

my @foo = orig_zip( \@a, \@b );
my @bar = fixed_zip( \@a, \@b );

print Data::Dumper->Dump( 
    [ \@foo,      \@bar   ], 
    [ 'original', 'fixed' ]
);

sub orig_zip {
    my( $r1, $r2 ) = @_;
    map {
        $r1->[ $_ ], $r2->[ $_ ]
    } 0 .. ( @$r1 > @$r2 ? @$r1 : @$r2 );
}

sub fixed_zip {
    my( $r1, $r2 ) = @_;
    map {
        $r1->[ $_ ], $r2->[ $_ ]
    } 0 .. ( $#$r1 > $#$r2 ? $#$r1 : $#$r2 );
}
__END__
$original = [
              1,
              'a',
              2,
              'b',
              3,
              'c',
              undef,
              undef
            ];
$fixed = [
           1,
           'a',
           2,
           'b',
           3,
           'c'
         ];
[download]


TGI says moo

Ew. Copying both arrays to avoid destroying them is horribly inefficient. As is building an array only to return it as a list

You can't judge code performance by eyeballing it. Let's try a simple measurement instead.

Here's my benchmark code (hopefully without any embarrassing mistakes! unfortunately with an embarrassing mistake):

Read more... (1061 Bytes)

And here are the (misleading) results:

For 10 elements:
           Rate deref  copy  CPAN
deref  672475/s    --  -15%  -67%
copy   795069/s   18%    --  -62%
CPAN  2066450/s  207%  160%    --

For 1000 elements:
           Rate deref  copy  CPAN
deref  671925/s    --  -14%  -68%
copy   781043/s   16%    --  -62%
CPAN  2071516/s  208%  165%    --

For 10000000 elements:
           Rate deref  copy  CPAN
deref  653053/s    --  -15%  -68%
copy   771081/s   18%    --  -62%
CPAN  2045217/s  213%  165%    --
[download]

So, we have one unsurprising result: optimised, tested, standard CPAN code (List::MoreUtils::zip) is significantly more efficient than reinventing the wheel. :)

And we have a surprising result, too: copying and shifting may look less efficient than dereferencing, but in practice it's a good 15% faster -- in this particular instance, on my particular computer (Linux 2.6, x86_64, Perl 5.8.8), that is.

Wait, have I got this right? It seems odd that the speed changes so little as I change the length of the lists. Hmm.

Update: yup, I was wrong; blasted scoping rules hiding my arrays from the evalled code. BrowserUk's corrected benchmark (below) shows that the dereferencing version is significantly faster than the copying version, and its advantage increases as the arrays grow. However, List::MoreUtils::zip does still outperform both, particularly on shorter arrays.