Consider that

  foreach ( sort keys %h ) {
      ...
      $h{$new} = $new;
[download]

  @sorted = sort keys %h;
  foreach ( @sorted ) {
      ...
     $h{$new} = $new;
[download]

By the way, the "next;" is redundant.

Well, thanks. But without "sort" it works the same way. I wonder how it processes large arrays - always creates a copy?

--dda

Well, thanks. But without "sort" it works the same way.

I should have been more explicit. It's "keys" that creates the new array, not the sort.

If you want to process all of the keys and values in a hash without creating a new array to hold the hash keys, look into "each".

  while ( ($key, $value) = each %h ) {
      ...
[download]

This doesn't create an additional array. Note, though, that it's unsafe to manipulate the hash while you're iterating over it. The proviso in the docs reads:

If you add or delete elements of a hash while you’re iterating over it, you may get entries skipped or duplicated, so don’t. Exception: It is always safe to delete the item most recently returned by "each()".

> Probably, the list for looping is populated before the loop starts?

Yes.

You might want to try

while (my ($key, $value) = each(%h)) {
}
[download]

P.S. next; at the end of foreach block is redundant.

You might want to try {code with each} But I am not sure if you'll get all your new keys.

Actually, the docs for each specifically say that you should not do this - as each returns hash elements in an essentially random order (or at least in an unpredictable order), so doing something like this is playing with fire :).

CU
Robartes-

I always figured that each and related functions keys and values iterated over the hash from start to finish with the order being determined by the hashing algorithm. Can an internals person shed some light on what determines this "essentially random order"?

---

"The dead do not recognize context" -- Kai, Lexx

That's what I meant by "I am not sure if you'll get all your new keys." I guess it did not come across that way.

About "next": I added it while experimenting with the code. Thanks :)

--dda

For 'one by one' iteration over a hash, have a look at each, but you cannot use that to add elements to the hash on the fly while iterating over it either (well, you can, but it's your foot :) ).

You'll have to iterate over the hash keys again if you want to get at the new values, I think.

CU
Robartes-

"You are correct - a foreach loop builds a temporary list, and iterates over that." I don't think this is true. Try this:

my @list = (1,2,3,4,5);
foreach (@list) {
  print $_."\n";
  push @list,$_.$_;
}
[download]

This makes an infinite loop (at least until your memory runs out), so it appears that foreach is actually using the original list

This is documented in perlsyn.

If any part of LIST is an array, foreach will get very confused if you add or remove elements within the loop body, for example with splice. So don't do that.

Setting aside the way Perl handles this specific case, ask yourself how a computer program could keep track of which items in a collection it had already processed, if items can be inserted into the middle of the collection during processing. The only way I know is to build a second list. There are two ways to do this: you can keep a list of ones you've already done, or a list of ones you haven't done yet. If your keys (in this case, the hash keys) have a defined order, you can in theory limit your list of not-done-yet ones somewhat by having "all the ones with a key greater than this value n" be one (possibly implicit) always-final entry in the list, adding entries to the list only when that doesn't cover them, and raising the value of n whenever it's the only item in the list. This requires some work on your part, though, and in most cases is probably not worth it. If your footprint is a significant issue, though, it is an option. Something along the lines of this...

$n = minimum_key(\%h); # minimum_key left as an exercise
while (@n or ($n<maximum_key(\%h))) { # also maximum_key
   if not (@n) {
      push @n, keys_between(\%h, $n, $n+1);
      # Yep, keys_between is also left as an exercise.
      $n++;
   }
   my $thiselement = shift @n;
   process_element($thiselement);
}
[download]

If you do something like this, be sure to be consistent with your inequalities (e.g., if an element is equal to n, it either has to be in @n or covered by $n but not both). Also of course if you insert anything into the hash as part of the processing you have to test whether the key is less than $n and if so add it to @n.

for(unpack("C*",'GGGG?GGGG?O__\?WccW?{GCw?Wcc{?Wcc~?Wcc{?~cc'
.'W?')){$j=$_-63;++$a;for$p(0..7){$h[$p][$a]=$j%2;$j/=2}}for$
p(0..7){for$a(1..45){$_=($h[$p-1][$a])?'#':' ';print}print$/}
[download]

You would have (or could create) an infinite loop.

Cheers - L~R

Update: As fletcher_the_dog pointed this behavior does create the infinite loop for an array (not hash), and as pointed out by Mr. Muskrat that this is a known deficiency and it should be avoided.

I have been monitoring this thread for most of the day and as far as I can tell, no one has stated the obvious.

There is such a thing as letting people discover their next problem. If we solve it for them before they encounter it, how will they learn?

#! c:/perl/bin/perl.exe

use strict;
use warnings;

my %h = (
  1 => 1111111,
  2 => 2222222,
  3 => 3333333,
  4 => 4444444,
  5 => 5555555,
);

my $ind = 0;
my $item = (sort(keys(%h)))[$ind++];
do {
    print "Processing $item \n";
    my $new = $item*10;
    $h{$new} = $new;
    print "   Addding $new\n";
    $item = (sort(keys(%h)))[$ind++];
} while (1);

print 'good luck \n';
[download]

#! c:/perl/bin/perl.exe

use strict;
use warnings;

my %h = (
  1 => 1111111,
  2 => 2222222,
  3 => 3333333,
  4 => 4444444,
  5 => 5555555,
);

my $ind = 0;
my $item = (sort(keys(%h)))[$ind++];
do {
    print "Processing $item \n";
    my $new = $item*10;
    $h{$new} = $new;
    print "   Addding $new\n";
    $item = (sort(keys(%h)))[$ind++];
} while (1);

print 'good luck \n';
[download]

20030417 Edit by Corion: Added code tags