ReadKey like Function in C

Sean Fagan seanf at sco.COM
Wed Aug 16 15:14:17 AEST 1989


In article <225800206 at uxe.cso.uiuc.edu> mcdonald at uxe.cso.uiuc.edu writes:
>FIX THEIR OPERATING SYSTEMS SO IT WILL WORK

This can be interpreted two ways (ambiguous, you know), and eitehr way is,
imnsho, wrong.

I have *yet* to *really* encounter a need to get a key as soon as it's
pressed.  If the ability is available, I might design things differently
than if it weren't, but it's not something that will kill me if it's not
there.  The *only* place I've seen a need for something like that is in
games, which, I regret to inform you, are not the staple of most
programmers.

Just because an OS does efficient I/O does not mean it is broken.  Also, as
someone else pointed out (Chris Torek?), it is not cost-efficient to do this
for most OS's.  IBM's virtual card punch is his example; I prefer NOS's
virtual tape file, since Cyber's were much faster than IBM's in their day
(and for quite a few days afterwards).

Sometime when you can, take a look at sam running on a blit-type terminal.
It doesn't require single-character I/O, yet, according to the people who
use it, it's the greatest thing since sliced bread.  FSE on the cyber's
didn't require it, and it worked fine, despite what other people might say.

Face it:  how to do such a thing is an OS-specific feature.  If you must
know the truth, I question malloc's need to be in the standard.  However, it
is necessary to write portable, *useful* programs, so it should be in there.
Doing scio is, however, *not* necessary for the same.

Incidently, I didn't see you require a method of turning echoing off and on;
why not?  A request for that comes up about as often as "ReadKey()" does,
and is about as portable and useful.

As other people pointed out, if a standard requires a feature that cannot be
implemented, than nobody will use the standard.

-- 
Sean Eric Fagan  |    "Uhm, excuse me..."
seanf at sco.UUCP   |      -- James T. Kirk (William Shatner), ST V: TFF
(408) 458-1422   | Any opinions expressed are my own, not my employers'.



More information about the Comp.lang.c mailing list