By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,949 Members | 890 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,949 IT Pros & Developers. It's quick & easy.

question about cin

P: n/a
I found the following code fragment in the C++ Primer(Fourth Edition)
by Stanley Lippman in page 213.

string inBuf;

while (cin >inBuf && ! inBuf.empty( ) )
{
// do something
}

Here is the condition check ( ! inBuf.empty() ) needed ?
is it possible that the expression ( cin >inBuf ) is true but still
inBuf is empty ?

Kindly explain.

Jun 19 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Hmmmm... This seems like some very odd coding to me, however I would
expand it to this:

while (1)
{
cin >inBuf;
if (inBuf != null)
{
// do something
}
else break;
}
// end of program

Basically, the program gets input. If the input is not null it
continues to process. If it is null, it ends. Here might be an example
of usage:

while (cin >(int) integerValue && integerValue != null )
{
counter += inegerValue;
cout << counter << "\n";
}
cout << "\n\nThe total is: " << counter;

It is essentially a null terminated loop. _I think_

Jun 19 '07 #2

P: n/a
su**************@yahoo.com, India wrote:
I found the following code fragment in the C++ Primer(Fourth Edition)
by Stanley Lippman in page 213.

string inBuf;

while (cin >inBuf && ! inBuf.empty( ) )
{
// do something
}

Here is the condition check ( ! inBuf.empty() ) needed ?
is it possible that the expression ( cin >inBuf ) is true but still
inBuf is empty ?
Let's see. The part cin >inBuf evaluates to cin which then converts via
void* to bool. The value is !(cin.fail()). However, if the extraction
operator does not actually extract some operators, it will set the failbit
[see 21.3.7.9/2a] Thus, if cin>>inBuf converts to true, we know that the
failbit was not set and thus at least one character was extracted.

Hence, the loop above should be equivalent to:

string inBuf;
while ( cin >inBuf ) {
assert( ! inBuf.empty() ); // [see 21.3.7.9/2a]
// do something
}
Best

Kai-Uwe Bux
Jun 19 '07 #3

P: n/a
On Jun 19, 9:49 am, Kai-Uwe Bux <jkherci...@gmx.netwrote:
Let's see. The part cin >inBuf evaluates to cin which then converts via
void* to bool. The value is !(cin.fail()). However, if the extraction
operator does not actually extract some operators, it will set the failbit
[see 21.3.7.9/2a] Thus, if cin>>inBuf converts to true, we know that the
failbit was not set and thus at least one character was extracted.

Hence, the loop above should be equivalent to:

string inBuf;
while ( cin >inBuf ) {
assert( ! inBuf.empty() ); // [see 21.3.7.9/2a]
// do something
}

Best

Kai-Uwe Bux
My doubt still persists since I am a beginner. As you have mentioned
that at least one character would have been extracted if (cin >>
inBuf) were to be true, it means that inBuf is non-empty; isn't it ?
Then why do we require the checking
( ! inBuf.empty() ).

Kindly explain

Thanks
V.Subramanian

Jun 20 '07 #4

P: n/a
su**************@yahoo.com, India wrote:
On Jun 19, 9:49 am, Kai-Uwe Bux <jkherci...@gmx.netwrote:
>Let's see. The part cin >inBuf evaluates to cin which then converts via
void* to bool. The value is !(cin.fail()). However, if the extraction
operator does not actually extract some operators, it will set the
failbit
[see 21.3.7.9/2a] Thus, if cin>>inBuf converts to true, we know that the
failbit was not set and thus at least one character was extracted.

Hence, the loop above should be equivalent to:

string inBuf;
while ( cin >inBuf ) {
assert( ! inBuf.empty() ); // [see 21.3.7.9/2a]
// do something
}

Best

Kai-Uwe Bux

My doubt still persists since I am a beginner. As you have mentioned
that at least one character would have been extracted if (cin >>
inBuf) were to be true, it means that inBuf is non-empty; isn't it ?
Correct, inBuf is non-empty inside the loop. That is the content of the
assert.
Then why do we require the checking
( ! inBuf.empty() ).
We don't require anything. I just put the assert in as a comment and as a
reminder for readers who may not know about [21.3.7.9/2a]. You can take it
out without loss (well, maybe you loose some verbosity and explicitness in
the code). In fact, if you compile the program with NDEBUG defined, the
compiler will take out the assert for you.
Best

Kai-Uwe Bux
Jun 20 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.