@hash{@list} x= 0;
which is still odd (and gives a warning for using uninitialized values), but is at least documented, if your code is bottlenecking at your key-creation section. In the absence of a bottleneck, it is better to write clear code than marginally faster code.
Caution: Contents may have been coded under pressure.
| [reply] [d/l] |
my $foo;
sub context :lvalue { $foo = wantarray ? 'list' : 'scalar' }
context() x= 1;
print $foo;
__END__
scalar
or using simpler means:
use Data::Dumper;
my %foo = qw/ a 1 b 2 /;
@foo{qw/ a b /} x= 0;
print Dumper \%foo;
__END__
$VAR1 = {
'a' => '1',
'b' => ''
};
A trick that does work though is the reference trick. All these other solutions work because of autovivification. So let's use \ whose behaviour explicitly is documented.
\@foo{@list};
ihb
See perltoc if you don't know which perldoc to read!
| [reply] [d/l] [select] |
The fact is that your x= tricks works is just as much as the undef() because of undocumented behaviour.
No, the behavior of assignment and the x operator are defined for array slices. If you don't like the zero, one works just as well.
That said, I like the ref trick. It's fast, documented, and not too bizarre. ++
I've thought about it a little more, and I wonder whether it actually is documented behavior. Is \ documented for array slices? Dumper tells me it's behaving like \(), making a list of references, which is sensible. I guess a slice is a list, even without surrounding parentheses...
Caution: Contents may have been coded under pressure.
| [reply] |
| [reply] |
When I pointed out that your examples were not good code, your response was to direct me, without further explanation, to another post which had recommended the same thing based on a slight speed advantage. So I had to surmise your reasoning: if you were defending the code based on the fact that someone else did it, it's cargo cultism; if you were defending the code based on the slight speed advantage, it's micro-optimization.
The OP's question indicates a low level of experience (it is in the FAQ, after all -- perldoc -q duplicate). Novices especially need to be given good examples. You can't just throw bad examples at them without any warning. They don't have the experience they need to be able to judge for themselves.
If you didn't realize that they were bad examples, well, that's why we have the ability to respond. Everybody throws out bad answers once in a while, and having them corrected is a Good Thing.
Caution: Contents may have been coded under pressure.
| [reply] [d/l] |