How, exactly, does kbhit( ) work?

[hugo27]

Re: [OT] Re: How, exactly, does kbhit( ) work?

k_amir7@yahoo.c om (kal) wrote in message news:<a5da4cc1. 0407010646.27f8 ec93@posting.go ogle.com>...[color=blue]
> rlb@hoekstra-uitgeverij.nl (Richard Bos) wrote in message news:<40e26c72. 498691578@news. individual.net> ...
>[color=green]
> > MT generally stands for Machine Translation.[/color]
>
> Thank you! I would have never thought of that.
>[color=green]
> > The OP must be trying to determine whether the buffer
> > contains language, or half-grammatical tripe.[/color]
>
> Tripe can be nutritious (vegetarians please try rock-tripe.)
> Here, in good ole Confederate Country, we are fond of chitlins.
>[color=green]
> > Actually, _really_ modern compilers consider such crudities
> > as <conio.h> to be beneath them.[/color]
>
> Of course, of course! BENEATH me is Mother Earth and seems to
> be none the worse for it. In fact, I am rather fond of Her.
>[color=green]
> > It's only those that try to be deceptively
> > almost-compatible with old compilers that support _kbhit().[/color]
>
> True, true! But some of us have to make do with these
> dastardly deceptive denizens of almost-compatible land.
>[color=green]
> > It's completely wrong.[/color]
>
> Tres bon. COMPLETELY wrong is as good as completely right.
>[color=green]
> > _kbhit() is actually part of the Improved Luser Education
> > Extensions (and therefore can be found in <ilee.h>),[/color]
>
> You don't say! Now, who would have thunk it?
>[color=green]
> > and what it stands for is Killfile Bozo and Hit it.[/color]
>
> How clever! One would have thought it would be "_kbhiti".
>[color=green]
> > What it does is to automatically put the user who invokes
> > it in the company killfile, and then hit him sharply over
> > the head with the robot arm mallet found in the ILEE
> > hardware option pack.[/color]
>
> No doubt the "option pack" is a marketing ploy to extract
> more money from the populi. Alas, there are some of us
> who can ill afford such luxuries.
>[color=green]
> > There is a related function called _kbshock(),[/color]
>
> kbs hock? How interesting!
> Reminds me of ham hock, perhaps a side effect of chitlins.
>[color=green]
> > which can be used to put bozos who post long, off-topic
> > posts to comp.lang.c in the Usenet killfile, and then punish
> > them in a similar way involving the keyboard and 5000 volts;[/color]
>
> Merci bien! I am gald it is only volts (may Alessandro
> Volta forgive me.) One is used to many times that opening
> car doors on wintry days. Were it current (pardonnez moi,
> André-Marie Ampère) it could be dangerous.
>[color=green]
> > you should be grateful it hasn't been compiled into
> > Google Groups yet.[/color]
>
> Sum, sum. I am very grateful. But I do have this nagging
> feeling that "its" are LINKED into rather than COMPILED
> into. No doubt I am quite mistaken as usual.
>[color=green]
> > Indeed. For example, Mr. Schildt may have assumed that
> > his readers can't distinguish "void" from "int".[/color]
>
> I do not know. I have never had the pleasure of accosting
> Herr. Schildt with that or any other inquiry.
>[color=green]
> > You could also learn to program portably instead of
> > obsoletely.[/color]
>
> We will, we will! Unfortunately, at present, some of our
> customers are using non-portable computers.
>[color=green]
> > Richard[/color]
>
> M. Richard, I deeply regret for offending your exquisite
> sensibilites. Kindly accept my sincere condolences.
>[color=green]
>>hugo27 July 1, 2004[/color]
>What talk! I was going to thank you for your help,
>but now cann't tell what's help.
>My question(the subject) is clearly OT(i see now), but my problem
>is not. I was assuming, perhaps unawares, that there
>was one buffer at issue, but I think now there are two.
>One is made by C in memory, and is connected with stdin,
>or is stdin. The other buffer is internal to the keyboard
>control system, and it is this buffer that kbhit looks at.
>
>Do these two buffers interact or do they operate independently?
>Either way, in my test code, by the time kbhit executed
>the internal buffer was empty(MT) or never received the data
>(it went directly to stdin). That's why kbhit returned 0.
>My problem, then, is to test stdin for empty/not empty.
>Is this possible in standard C?
>
>hugo[/color]

[Keith Thompson]

Re: [OT] Re: How, exactly, does kbhit( ) work?

obrhy8@yahoo.co m (hugo27) writes:
[...]

hugo:

When you reply to a message, please don't prefix your own new text
with '>' characters. It makes your entire article look like it's just
quoting a previous article, and is likely to cause it to be ignored.

It's also a good idea to trim most of the article to which you're
replying, leaving just enough to make the context clear.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dan Pop]

Re: [OT] Re: How, exactly, does kbhit( ) work?

In <rvlgr1-pvh.ln1@loki.si lversapphire.co m> Kelsey Bjarnason <kelseyb@lights peed.ca> writes:
[color=blue]
>[snips]
>
>Dan Pop wrote:[color=green]
>> It was *your* mistake it to extrapolate it to a different context than
>> the one intended by the poster.[/color]
>
>You mean, lke, say, the context of _C_, which is exactly what we discuss
>here? :)[/color]

If this was the intended context, then why the [OT] tag? ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de