Re^2: Looping through a hash reference is creating a key...?

[Roy Johnson]

I'm going to quibble with your advice regarding exists, which could be right or wrong depending on how one reads it. (I don't doubt that your understanding is correct, but I think others might read it differently than you intended.) Autovivification (the creation of intermediate references) is not prevented by using exists, so exists $h{1}{2} still creates $h{1}.

To prevent autovivification, one would have to test exists $h{1} and only if it were true, examine $h{1}{2}. However, they could just test whether $h{1} were true and get pretty much the same result -- if it didn't exist before, it won't exist after. The only difference in using exists is if $h{1} has a non-reference value like zero, empty string, or undef. It seems a little odd to dereference it in those cases. Perhaps a better idea would be to test it with ref.

[perrin]

Good point. I remember finding that out the hard way when I wrote some code that did exists() checks on deeply nested nodes in a huge data structure. My exists checks made the structure grow about 10MB in memory! Adding uglier but more careful code (if (exists $h{1} && exists $h{1}->{2} && exists ...) made the problem go away.

[thor]

I have to wonder if exists could be patched to not have this behavior. Short-circuiting comes to mind. If $h{1} doesn't exist, $h{1}{2} certainly won't. I'd look at it, but I can't code my way out of a paper bag in C. Plus, I have to believe that I'm not the first person to come up with such a notion.

[dave_the_m]

I have to wonder if exists could be patched to not have this behavior. Short-circuiting comes to mind.

It wouldn't be easy. By the time the exists op is called, all but one of the derefs has already taken place. IE exists is essentially a binary operator taking a hash and key as args:

exists $hash{a}{b}{c}

is executed as:

exists(%{$hash{a}{b}}, 'c')

Dave.