🚀 go-pugleaf

chip@ateng.ateng.com (Chip Salzenberg) writes:
>After all, if a given algorithm is non-portable and is therefore surrounded
>by "#ifdef MSDOS"/"#endif", why bother trying to make its implementation
>portable?
>
>For an example:  Name a portable way to get the complete shift state of a
>keyboard.  No, wait, that's too hard.  Name a portable way to *express* the
>complete shift state of a keyboard.  Code involving such an entity is non-
>portable from the get-go; so there's no reason to avoid non-portable coding
>in its implementation.

Wellll, it's true that it's not worthwhile to squeeze the last bit of annoying
unportable code out, if there is such a last bit.  However, I believe that most
of the guidelines for portable programming are also good guidelines for robust
programming, and in particular even though something may be intrinsically
ms-dos dependent in might not be ms-dos v3.3.1 dependent, and more portable
programming techniques can make your code more likely to survive an operating
system upgrade.  (Or compiler upgrade (or change), for that matter.)

ajr

--
"The goto statement has been the focus of much of this controversy."
	    -- Aho & Ullman, Principles of Compiler Design, A-W 1977, page 54.