is cin always the keyboard's input?

[Bob Smith]

question in subject.
does the standard say anything about this or is it platform dependent?
any advice much appeciated
/B

[stephan beal]

Bob Smith wrote:

question in subject.
does the standard say anything about this or is it platform dependent?
any advice much appeciated

Indeed, the whole point of 'cin' is to keep this detail hidden from you. It
is not only platform-dependent, but case-dependent.
e.g., when you do any of the following:

cat file | myapp
myapp < file

these are instructing the system to use the file (more specifically, the
input stream) as cin.
See section 15.17 in:
http://www.parashift.com/c++-faq-lite/input-output.html

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

[tom_usenet]

On Wed, 15 Oct 2003 16:00:36 +0300, Bob Smith <bo******@jippi i.fi>
wrote:

question in subject.
does the standard say anything about this or is it platform dependent?

Platform dependent. Often input is a file anyway:

cat "file.txt" | myprog

The above pipes a file into the standard input of myprog (on unix at
least). Alternatively, cin might be a serial port connection (on an
embedded device), or a telepathic connection to your brain. It is just
the standard stream-based input to a program.

Tom

[Bob Smith]

stephan beal wrote:

Bob Smith wrote:

question in subject.
does the standard say anything about this or is it platform dependent?
any advice much appeciated

Indeed, the whole point of 'cin' is to keep this detail hidden from you. It
is not only platform-dependent, but case-dependent.
e.g., when you do any of the following:

cat file | myapp
myapp < file

these are instructing the system to use the file (more specifically, the
input stream) as cin.
See section 15.17 in:
http://www.parashift.com/c++-faq-lite/input-output.html

well here is my problem:
m_reading is a bool value, qDebug(...) is a qt function, qxevent is a
class which can red from streams.
<snip>

if ( !m_reading ){
if ( std::cin.rdbuf( )->in_avail() ){
m_reading = true;
qDebug( "reading... ");
QxEvent e;
while( cin >> e ) {
m_event_queue.p ush( e );
counter++;
}
qDebug( "...read!") ;
m_reading = false;
}else{
qDebug("..no data" );
}
}else{
qDebug("already reading, return to caller");
}
qDebug("ready") ;
</snip>

Now, trying to output data from one program, to this program, like
../testdatamaker|./eventlogger

( testdatamaker is a program for making up testdata for eventlogger )

testdatamaker outputs strings every second, and eventlogger polls the
cin stream continuously, but it never receives any data, it always
returns with "no data".

So the whole idea with my application is that it should read the input
stream, that being any output from any program, piped, and make display
data out of it.

I feel silly to ask but what is going wrong ?*s*

any help *very* much appreciated.
thank's
/B

[stephan beal]

Bob Smith wrote:

well here is my problem:
m_reading is a bool value, qDebug(...) is a qt function, qxevent is a
class which can red from streams. ....
I feel silly to ask but what is going wrong ?*s*

any help *very* much appreciated.

i'm not a master of streams, so i don't have any suggestions except:
- have you tried using one of Qt's stream classes instead of std::istream?
- are the input fields properly terminated? (i can't say what QxEvent
expects there.) i'm assuming you're using ostream << QxEvent to create the
records, in which case the answer would of course be, "yes."

i can't find QxEvent in the online docs at trolltech, so haven't read up on
this class.

http://doc.trolltech.com/3.2/qxevent.html
redirs me to:
http://doc.trolltech.com/3.2/qevent.html

--
----- stephan beal
Registered Linux User #71917 http://counter.li.org
I speak for myself, not my employer. Contents may
be hot. Slippery when wet. Reading disclaimers makes
you go blind. Writing them is worse. You have been Warned.

[Stewart Gordon]

While it was 15/10/03 2:00 pm throughout the UK, Bob Smith sprinkled
little black dots on a white screen, and they fell thus:

question in subject.
does the standard say anything about this or is it platform dependent?
any advice much appeciated

Standard C++ knows nothing of keyboards.

cin is the standard input, whatever that may be. Typical examples are
console input, a pipe or a file.

And even console input is seldom the keyboard directly. It is generally
a mechanism that reads input lines and then transmits them to the
program, line by line. Even these input lines need not come straight
from the keyboard - e.g. if the console is in a GUI setting, chances are
it supports copy and paste.

Stewart.

--
My e-mail is valid but not my primary mailbox. Please keep replies on
on the 'group where everyone may benefit.

[tom_usenet]

On Wed, 15 Oct 2003 16:18:53 +0300, Bob Smith <bo******@jippi i.fi>
wrote:

stephan beal wrote:

Bob Smith wrote:

question in subject.
does the standard say anything about this or is it platform dependent?
any advice much appeciated

Indeed, the whole point of 'cin' is to keep this detail hidden from you. It
is not only platform-dependent, but case-dependent.
e.g., when you do any of the following:

cat file | myapp
myapp < file

these are instructing the system to use the file (more specifically, the
input stream) as cin.
See section 15.17 in:
http://www.parashift.com/c++-faq-lite/input-output.html

well here is my problem:
m_reading is a bool value, qDebug(...) is a qt function, qxevent is a
class which can red from streams.
<snip>

if ( !m_reading ){
if ( std::cin.rdbuf( )->in_avail() ){

in_avail will generally be 0 if you haven't attempted a read operation
- it usually just returns the number of characters buffered by the
underlying streambuf. You need to
a) Set stdin to non-blocking mode (in an OS specific way)
b) Try reading something from cin to fill the buffer.
m_reading = true;
qDebug( "reading... ");
QxEvent e;
while( cin >> e ) {
m_event_queue.p ush( e );
counter++;
}
Here the stream will be in an error state (eof). All operations on
such a stream will fail. Add here:

if (cin.eof())
{
cin.clear();
}
else
{
//something serious has gone wrong.
qDebug(strerror (errno)); //or whatever.
throw something;
}
qDebug( "...read!") ;
m_reading = false;
}else{
qDebug("..no data" );
}
}else{
qDebug("already reading, return to caller");
}
qDebug("ready") ;
</snip>

Here's my take on the code:

//set stream to non-blocking

if ( !m_reading ){
m_reading = true;
qDebug( "reading... ");
QxEvent e;
while( cin >> e ) {
m_event_queue.p ush( e );
counter++;
}
if (cin.eof())
{
cin.clear(); //clear error state
}
else
{
throw serious_error() ;
}
qDebug( "...read!") ;
m_reading = false;
}else{
qDebug("already reading, return to caller");
}
qDebug("ready") ;

Alternatively, just set the stream to blocking so that process b waits
for data. You could always put the busy wait in its own thread in b.

Usually you use the posix "select" call to handle this kind of code.

Tom

[Rolf Magnus]

tom_usenet wrote:

in_avail will generally be 0 if you haven't attempted a read operation

Stroustrup says something different in TC++PL. According to him, you can
use in_avail _before_ a read attempt to find out if that read operation
would block.

[Ron Natalie]

"Rolf Magnus" <ra******@t-online.de> wrote in message news:bm******** *****@news.t-online.com...

tom_usenet wrote:

in_avail will generally be 0 if you haven't attempted a read operation

Stroustrup says something different in TC++PL. According to him, you can
use in_avail _before_ a read attempt to find out if that read operation
would block.

He does not say that and Rolf is right. What Stroustrup says is that if in_avail
is positive, then you won't block. The inverse is not true, that if in_avail is zero
you will block.

in_avail only tells you if there is characters in the stream's buffer. While you can
be guaranteed of reading that many characters without blocking (because they're
already in the buffer). However if it is zero or negative, it means a low-level read will have
to occur to get something in the buffer. Whether this will block or not is unknown
to the stream buffer classes.

As Rolf said, if you open a stream and you haven't done any reads, there's nothing
in the buffer and in_avail will be zero. The same is probably true if you read exactly
in_avail characters later.

[Bob Smith]

Ron Natalie wrote:

"Rolf Magnus" <ra******@t-online.de> wrote in message news:bm******** *****@news.t-online.com...

tom_usenet wrote:

in_avail will generally be 0 if you haven't attempted a read operation

Stroustrup says something different in TC++PL. According to him, you can
use in_avail _before_ a read attempt to find out if that read operation
would block.

He does not say that and Rolf is right. What Stroustrup says is that if in_avail
is positive, then you won't block. The inverse is not true, that if in_avail is zero
you will block.

in_avail only tells you if there is characters in the stream's buffer. While you can
be guaranteed of reading that many characters without blocking (because they're
already in the buffer). However if it is zero or negative, it means a low-level read will have
to occur to get something in the buffer. Whether this will block or not is unknown
to the stream buffer classes.

As Rolf said, if you open a stream and you haven't done any reads, there's nothing
in the buffer and in_avail will be zero. The same is probably true if you read exactly
in_avail characters later.

Hi again,
here is some code
<snip>

//testdatamaker
#include <iostream>
#include <strstream>
#include <unistd.h>
int main(void){
for ( int c = 0; c < 100;c++){
sleep(1);
strstream s;
s << "key " << c << ":data->" << c << endl;
cout << s.str();
}
}



//testdatasink
#include <iostream>
int main(void){
char c;
while ( cin >> c ) cout << c;
}
../testdatamaker|./testdatasink
doesn't work because the testdatamaker sleeps one second for 100 times
and doesn't flush teh cout.
//new testdatamaker
....
cout << s.str();
cout.flush();//<<--note
....
../testdatamaker|./testdatasink

now works.the testdatasink receives the data in real time.
let's test in_avail()
///test in_avail()
#include <iostream>
#include <unistd.h>
bool has_data();
int main(void){
while( 1 ){
if ( has_data() ){
char c;
while( cin >> c ) cout << c;
}else{
cout << "no data..." << endl;
sleep(1);
}

}
}
bool has_data(){
cout << "cin.rdbuf( )->in_avail() returns:" << cin.rdbuf()->in_avail()
<< endl;
return cin.rdbuf()->in_avail();
}
always returns "no data". has_data() always gives zero( 0 ) calling
cin.rdbuf()->in_avail().
in_avail() is broken on my linux box. or perhaps poorly implemented.
need to look for a new way of getting piped data.

any help much appreciated.

/B