no warnings 'uninitialized';
Makeshifts last the longest. | [reply]
[d/l] |
Yes, but note the line "I've two arrays containing an equal number of digits". If you already know that a certain type of error will not occur, why bother doing extra programming to prevent it? Computers don't just get up in the morning and decide to give you letters instead of numbers as an April Fool's Day joke.
This reminds me of an old game called Robot Odyssey that Dad and I used to play on our Apple IIE. There's a certain puzzle where your robot has to travel through a dark room from one side to the other, dodging all the force fields scattered around. Your character isn't allowed to go into the room himself, which is why you have to send the robot. Dad spent days carefully programming the robot to make the entire trek on its own. I looked over the problem for about five minutes, then put my character inside the robot and manually wired it for each separate movement. Perhaps my way wasn't the most elegant solution, but who cares as long as I made it to the objective? | [reply] |
If you already know that a certain type of error will not occur, why bother doing extra programming to prevent it?
Encountering undef values in the array was also a case of "a certain type of error will not occur". But it did, due to the one-off error. But supposing there was a valid reason to be seeing undef's in the arrays; you don't want to turn off other warnings that might indicate different errors.
Computers don't just get up in the morning and decide to give you letters instead of numbers as an April Fool's Day joke.
Sure they do; we get it reported here all the time, with code that looks like:
sub foo { while (<INPUT>) { ... } }
for (@array_of_numbers) {
...
foo()
...
}
| [reply]
[d/l] |