How, exactly, does kbhit( ) work?

[hugo27]

June 28, 2004
I'm interested in finding a way to test the keyboard buffer
for MT/Not MT. Tried kbhit() in system.h but it didn't do
what I thought it would from reading the literature.
Samples: Compiler Docs said,
"Detects whether a keypress is available for reading."

Herbert Schildt said,
"If the user has pressed a key, this function returns
true(non-0), but does not read the character.
If no keystroke is pending, kbhit() returns false (0)."

Here is the test code. kbhit() executes between two
getchar() calls.
#include <stdio.h>
#include <system.h>
void main() {
int ig1=0, ig2=0, ik=-1;
ig1 = getchar();
ik = kbhit();
ig2 = getchar();
getchar();
printf("ig1=%d, ik=%d, ig2=%d", ig1,ik,ig2);
return;
}

At runtime, I pressed aAEnter, so that 'A' and '\n'
were in buffer when kbhit() executed, yet ik returned
as 0.
Where else would a keystroke be "waiting" or "available"
except in the buffer? If kbhit() does not look at the
buffer, what does it look at?

 

[Joona I Palaste]

June 28, 2004
I'm interested in finding a way to test the keyboard buffer
for MT/Not MT. Tried kbhit() in system.h but it didn't do
what I thought it would from reading the literature.
Samples: Compiler Docs said,
"Detects whether a keypress is available for reading."

Herbert Schildt said,
"If the user has pressed a key, this function returns
true(non-0), but does not read the character.
If no keystroke is pending, kbhit() returns false (0)."

There is no kbhit() function in ISO standard C. Please ask in
comp.os.ms-windows.programmer.misc or a suitable Microsoft newsgroup.

 

[Martin Ambuhl]

June 28, 2004
I'm interested in finding a way to test the keyboard buffer
for MT/Not MT.

There is no support for such things in the standard C libraries. You
will need implementation-specific functionality for this. You need,
then, to check newsgroups, mailing lists, or tech support for your
implementation.

Tried kbhit() in system.h but it didn't do

what I thought it would from reading the literature.
Samples: Compiler Docs said,
"Detects whether a keypress is available for reading."

Herbert Schildt said,
"If the user has pressed a key, this function returns
true(non-0), but does not read the character.
If no keystroke is pending, kbhit() returns false (0)."

Herbert Schildt is one of the primary providers on misinformation on C.
Ignore him unless he is writing documentation for your specific
implementation.

 

[Malcolm]

Where else would a keystroke be "waiting" or "available"
except in the buffer? If kbhit() does not look at the
buffer, what does it look at?

stdin treats the keyboard as a device that provides a steady stream of
characters, which become avialble to the program when the user types enter.
This isn't the only way to treat the keyboard. For instance if you are
writing a game of space invaders you want to know if the key is pressed at
the very instant you make the test. This is where functions like kbhit()
(not an ANSI function) come in useful. Implementation varies, but probably
it looks at the internals of the keyboard driver - characters on the command
line are obviously stored somewhere, even though they are not yet entered to
the stdin buffer.

 

[kal]

June 28, 2004
I'm interested in finding a way to test the keyboard buffer
for MT/Not MT.

What is MT? Does it stand for "empty?"

Tried kbhit() in system.h

You must be using an older compiler version. In newer ones

but it didn't do what I thought it would

I too have the same problem. Nothing ever happens the way
I think they should. e.g. They always pull different
numbers at the lotto draw than the ones I pick.

Samples: Compiler Docs said,
"Detects whether a keypress is available for reading."

This seems to be correct.

Herbert Schildt said,

Mr. Schildt may have assumed certain things about his readers.

#include <stdio.h>
#include <system.h>
void main() {
int ig1=0, ig2=0, ik=-1;
ig1 = getchar();
ik = kbhit();
ig2 = getchar();
getchar();
printf("ig1=%d, ik=%d, ig2=%d", ig1,ik,ig2);
return;
}

At runtime, I pressed aAEnter, so that 'A' and '\n'
were in buffer when kbhit() executed,

Ah, you are making assumptions. It is always hazardous to do so.

_kbhit() is a low level function. Its purpose is to detect if
any of the keys in the keyboard have been pressed since the last
call to _kbhit() or any of the associated low level functions.

yet ik returned as 0.

Rightly so.

Where else would a keystroke be "waiting" or "available"
except in the buffer?

The question is, which buffer? getchar() has its buffer but
_kbhit() may have its own buffer. We are talking about two
different LEVELS of routines.

Let us see what happens when the program runs:

1. Execution halts on the first getchar().

2. Operator presses the key "a", the charcater 'a' is
moved to the keyboard buffer by conio routines.

3. Operator presses the key "A", the charcater 'A' is
moved to the keyboard buffer by conio routines.

4. Operates presses the ENTER key, the character '\n'
is moved to the keyboard buffer by conio routines.

5. On detecting the addition of '\n' to they keyboard
buffer, the entire contentes of keyboard buffer are
moved to the stdin buffer (used by getchar.)

6. The first getchar() on which the program halted
detects availability of data in the stdin buffer
and returns the character 'a'.

7. _kbhit() is called which rightly returns 0 since
there is nothing in the keyboard buffer.

To get a nonzero return by _kbhit() what you need to do
is to hit one of the keys AFTER step (5) but BEFORE
step (6). There should be an interval of a few
nanoseconds for this in most systems.

OTOH, one may find it easier to use _getch() instead of
getchar(). Since _getch() is also a low level function
it works in conjunction with _kbhit().

 

[Kelsey Bjarnason]

[snips]

You must be using an older compiler version. In newer ones
the function is "_kbhit()" and it is declared in <conio.h>.

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

 

[Richard Bos]

What is MT? Does it stand for "empty?"

MT generally stands for Machine Translation. The OP must be trying to
determine whether the buffer contains language, or half-grammatical
tripe.

You must be using an older compiler version. In newer ones
the function is "_kbhit()" and it is declared in <conio.h>.

Actually, _really_ modern compilers consider such crudities as <conio.h>
to be beneath them. It's only those that try to be deceptively
almost-compatible with old compilers that support _kbhit().

This seems to be correct.

It's completely wrong. _kbhit() is actually part of the Improved Luser
Education Extensions (and therefore can be found in <ilee.h>), and what
it stands for is Killfile Bozo and Hit it. 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.
There is a related function called _kbshock(), 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; you should be grateful it hasn't been compiled into
Google Groups yet.

Mr. Schildt may have assumed certain things about his readers.

Indeed. For example, Mr. Schildt may have assumed that his readers can't
distinguish "void" from "int".

OTOH, one may find it easier to use _getch() instead of
getchar().

You could also learn to program portably instead of obsoletely.

Richard

 

[Dan Pop]

[snips]

You must be using an older compiler version. In newer ones
the function is "_kbhit()" and it is declared in <conio.h>.

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

In your humble opinion, what does the [OT] tag in the subject line mean?

Dan

 

[Arthur J. O'Dwyer]

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

In your humble opinion, what does the [OT] tag in the subject line mean?

Last I heard, it meant "Off Topic." But kal's statement was not
merely off-topic; it was WRONG WRONG WRONG. Kelsey pointed that
out in a somewhat humorous fashion.
If you're suggesting everyone simply ignore wrong advice posted
under an 'OT' flag, that's a defensible position. Certainly I think
everyone ought to ignore *correct* advice posted with 'OT' (since
there's nothing more to say to it), and *repeated malicious* bad advice
posted with 'OT' (since it's not going to get any better), but I see
nothing wrong with the occasional correction to apparently innocent
mistakes, even OT ones, if it's not disruptive.

<OT>
*My* libc has <conio.h>, and the function on *my* system is
called 'kbhit'. And they don't get any "newer" than this.
</OT>

-Arthur

 

[Dan Pop]

On Tue, 29 Jun 2004 17:09:46 -0700, kal wrote:
You must be using an older compiler version. In newer ones
the function is "_kbhit()" and it is declared in <conio.h>.

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

In your humble opinion, what does the [OT] tag in the subject line mean?

Last I heard, it meant "Off Topic." But kal's statement was not
merely off-topic; it was WRONG WRONG WRONG.

Nope, it was right in an off topic context. The context of the
implementation the poster was talking about (whatever that was).

If you're suggesting everyone simply ignore wrong advice posted
under an 'OT' flag, that's a defensible position.

I'm merely suggesting that information posted under the [OT] tag should
be treated as such. It makes no sense to interpret it in the context of
the c.l.c newsgroup (otherwise it wouldn't be off topic in the first
place).

<OT>

*My* libc has <conio.h>, and the function on *my* system is
called 'kbhit'. And they don't get any "newer" than this.

What makes you think that the OP was talking about *your* libc? ;-)

The inventor of kbhit and friends was Microsoft. Many of the Microsoft
extensions were already prefixed with an underscore, to make it obvious
that they were not standard features. Later, they wisely decided to
extend this practice to more of their extensions. To avoid breaking
existing code, they provided the non-prefixed names in a compatibility
library, something like oldnames.lib or so. I guess this is what kal
was talking about and he was not wrong, as long as [OT] is interpreted
the usual way: implementation/platform specific discussions or stuff that
doesn't have anything to do with C.

Dan

 

[kal]

MT generally stands for Machine Translation.

Thank you! I would have never thought of that.

The OP must be trying to determine whether the buffer
contains language, or half-grammatical tripe.

Tripe can be nutritious (vegetarians please try rock-tripe.)
Here, in good ole Confederate Country, we are fond of chitlins.

Actually, _really_ modern compilers consider such crudities
as <conio.h> to be beneath them.

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.

It's only those that try to be deceptively
almost-compatible with old compilers that support _kbhit().

True, true! But some of us have to make do with these
dastardly deceptive denizens of almost-compatible land.

It's completely wrong.

Tres bon. COMPLETELY wrong is as good as completely right.

_kbhit() is actually part of the Improved Luser Education
Extensions (and therefore can be found in <ilee.h>),

You don't say! Now, who would have thunk it?

and what it stands for is Killfile Bozo and Hit it.

How clever! One would have thought it would be "_kbhiti".

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.

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.

There is a related function called _kbshock(),

kbs hock? How interesting!
Reminds me of ham hock, perhaps a side effect of chitlins.

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;

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.

you should be grateful it hasn't been compiled into
Google Groups yet.

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.

Indeed. For example, Mr. Schildt may have assumed that
his readers can't distinguish "void" from "int".

I do not know. I have never had the pleasure of accosting
Herr. Schildt with that or any other inquiry.

You could also learn to program portably instead of
obsoletely.

We will, we will! Unfortunately, at present, some of our
customers are using non-portable computers.

Richard

M. Richard, I deeply regret for offending your exquisite
sensibilites. Kindly accept my sincere condolences.

 

[Kelsey Bjarnason]

[snips]

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

In your humble opinion, what does the [OT] tag in the subject line mean?

That the post probably doesn't belong here _at all_... but since it is
here, and contains definitively incorrect information - that "newer
compiler versions" - such as gcc 3.x - actually do have _kbhit() defined
in <conio.g> - it should, perforce, be corrected.

Yes, and?

 

[hugo27]

On Tue, 29 Jun 2004 17:09:46 -0700, kal wrote:
You must be using an older compiler version. In newer ones
the function is "_kbhit()" and it is declared in <conio.h>.

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

In your humble opinion, what does the [OT] tag in the subject line mean?

Last I heard, it meant "Off Topic." But kal's statement was not
merely off-topic; it was WRONG WRONG WRONG.

Nope, it was right in an off topic context. The context of the
implementation the poster was talking about (whatever that was).

If you're suggesting everyone simply ignore wrong advice posted
under an 'OT' flag, that's a defensible position.

I'm merely suggesting that information posted under the [OT] tag should
be treated as such. It makes no sense to interpret it in the context of
the c.l.c newsgroup (otherwise it wouldn't be off topic in the first
place).

<OT>

*My* libc has <conio.h>, and the function on *my* system is
called 'kbhit'. And they don't get any "newer" than this.

What makes you think that the OP was talking about *your* libc? ;-)

The inventor of kbhit and friends was Microsoft. Many of the Microsoft
extensions were already prefixed with an underscore, to make it obvious
that they were not standard features. Later, they wisely decided to
extend this practice to more of their extensions. To avoid breaking
existing code, they provided the non-prefixed names in a compatibility
library, something like oldnames.lib or so. I guess this is what kal
was talking about and he was not wrong, as long as [OT] is interpreted
the usual way: implementation/platform specific discussions or stuff that
doesn't have anything to do with C.

Dan

 

[Dan Pop]

[snips]

You must be using an older compiler version. In newer ones
the function is "_kbhit()" and it is declared in <conio.h>.

Funny... I'm running a very recent version of gcc, and it doesn't have a
kbhit at all... nor, apparently, a conio.h.

In your humble opinion, what does the [OT] tag in the subject line mean?

That the post probably doesn't belong here _at all_... but since it is
here, and contains definitively incorrect information - that "newer
compiler versions" - such as gcc 3.x - actually do have _kbhit() defined
in <conio.g> - it should, perforce, be corrected.

Yes, and?

If it contained accurate technical information, in the context of the
newsgroup, it wouldn't have been off topic in the first place. As it was,
it contained accurate technical information in a different context, hence
the [OT] tag.

It was *your* mistake it to extrapolate it to a different context than
the one intended by the poster.

Dan

 

[Kelsey Bjarnason]

[snips]

It was *your* mistake it to extrapolate it to a different context than
the one intended by the poster.

You mean, lke, say, the context of _C_, which is exactly what we discuss
here?

 

[hugo27]

Thank you! I would have never thought of that.


Tripe can be nutritious (vegetarians please try rock-tripe.)
Here, in good ole Confederate Country, we are fond of chitlins.


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.


True, true! But some of us have to make do with these
dastardly deceptive denizens of almost-compatible land.


Tres bon. COMPLETELY wrong is as good as completely right.


You don't say! Now, who would have thunk it?


How clever! One would have thought it would be "_kbhiti".


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.


kbs hock? How interesting!
Reminds me of ham hock, perhaps a side effect of chitlins.


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.


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.


I do not know. I have never had the pleasure of accosting
Herr. Schildt with that or any other inquiry.


We will, we will! Unfortunately, at present, some of our
customers are using non-portable computers.


M. Richard, I deeply regret for offending your exquisite
sensibilites. Kindly accept my sincere condolences.

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

 

[Keith Thompson]

(e-mail address removed) (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.

 

[Dan Pop]

[snips]

It was *your* mistake it to extrapolate it to a different context than
the one intended by the poster.

You mean, lke, say, the context of _C_, which is exactly what we discuss
here?

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

Dan