In more depth,
(1) Don't try really hard to think about the time overhead of memory allocation in one step or many. That's the computer's job. Your job is to write an effective algorithm. If the FINISHED program runs too slowly, THEN figure out why.
(2) When you use system calls, like open() and read(), then you should also check their returned values for any unexpected error conditions. When you use the high-level equivalents like <ARGV>, this is done for you in a generic, consistent way (die).
(3) When I'm designing code, I am at the beginning of the lifetime of the application. Any hardcoded "maximum size" constants are based on my best guess at the time, but somebody else might need to increase the complexity of that config file, or add more words to the dictionary, or any other mission creep. Someone's going to have to go in and find out why the application can't check the spelling of any words starting with Z. Someone's going to have to modify (and re-distribute) the application. There's a reason Perl doesn't require explicit string and array length allocations. Length should not be your concern.
(4) I use the read() function so seldom that I would have to look it up to see what the "maxsize" argument was, and then come to trust that if the file was shorter than this maximum, that it would indeed get read in its entirety. I already know that the slurp idiom works every time.
I didn't count off for use strict compliance, but remember to identify or declare all those lexicals accurately.
--
[ e d @ h a l l e y . c c ]
In reply to Re^2: shell vs. filehandler
by halley
in thread shell vs. filehandler
by 10basetom
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |