Problems with cin (already tried getline)

[Michele 'xjp']

Hi there.

I have some problems with cin. Here's the code:

http://rafb.net/p/GhK3AU65.html

If you press '6', and 'enter', it will have to ask for another insert of
a string. However, in this case, it goes straight without waiting for
input... any ideas?

[Zeppe]

Michele 'xjp' wrote:

Hi there.

I have some problems with cin. Here's the code:

http://rafb.net/p/GhK3AU65.html

If you press '6', and 'enter', it will have to ask for another insert of
a string. However, in this case, it goes straight without waiting for
input... any ideas?

yes, there is a \n in the buffer. Put cin.sync() after cin >scelta,
and everything will work ;)

Regards,

Zeppe

[=?ISO-8859-15?Q?Erik_Wikstr=F6m?=]

On 2007-07-19 22:12, Michele 'xjp' wrote:

Hi there.

I have some problems with cin. Here's the code:

http://rafb.net/p/GhK3AU65.html

Please post the code inline.

If you press '6', and 'enter', it will have to ask for another insert of
a string. However, in this case, it goes straight without waiting for
input... any ideas?

Because the enter you pressed after the 6 is still in the input buffer,
so the getline() will read that, and since it's the terminator chosen
(it's default by the way, you don't have to specify it) it will read in
an empty string.

By the way, why oh why:

#define clrscr() printf("\e[2J")

What's wrong with an inline function or something like that, don't you
know that macros are evil?

--
Erik Wikström

[Michele 'xjp']

Zeppe ha scritto:

Michele 'xjp' wrote:

>Hi there.

I have some problems with cin. Here's the code:

http://rafb.net/p/GhK3AU65.html

If you press '6', and 'enter', it will have to ask for another insert of
a string. However, in this case, it goes straight without waiting for
input... any ideas?

yes, there is a \n in the buffer. Put cin.sync() after cin >scelta,
and everything will work ;)

Regards,

Zeppe

I get the same problem with cin.sync()...

Solved with:
cin.ignore(INT_MAX, '\n' );

after the initially cin >scelta

Thank you!

[Obnoxious User]

On Thu, 19 Jul 2007 22:12:09 +0200, Michele 'xjp' wrote:

Hi there.

I have some problems with cin. Here's the code:

http://rafb.net/p/GhK3AU65.html

If you press '6', and 'enter', it will have to ask for another insert of
a string. However, in this case, it goes straight without waiting for
input... any ideas?

Always verify input data, and always verify the state of the input stream,
after each input.

--
Obnoxious User

[James Kanze]

On Jul 20, 12:03 am, Zeppe
<[e-mail] e:

Michele 'xjp' wrote:

yes, there is a \n in the buffer. Put cin.sync() after cin >scelta,
and everything will work ;)

cin is an input buffer; cin.sync() has no defined meaning.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jul 20, 11:39 am, Obnoxious User <O...@127.0.0.1wrote:

On Thu, 19 Jul 2007 22:12:09 +0200, Michele 'xjp' wrote:

I have some problems with cin. Here's the code:

http://rafb.net/p/GhK3AU65.html

If you press '6', and 'enter', it will have to ask for another insert of
a string. However, in this case, it goes straight without waiting for
input... any ideas?

Always verify input data, and always verify the state of the
input stream, after each input.

I'll second that. And if you want line oriented input, always
use getline, then (if necessary) istringstream to parse it.
Something like:

std::string line ;
getline( std::cin, line ) ;
std::istringstream l( line ) ;
int number ;
l >number >std::ws ;
if ( ! l || l.get() != EOF ) {
// We got a problem, somewhere between the keyboard
// and the chair.
}

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Zeppe]

James Kanze wrote:

On Jul 20, 12:03 am, Zeppe
<[e-mail] e:

>Michele 'xjp' wrote:

>yes, there is a \n in the buffer. Put cin.sync() after cin >scelta,
and everything will work ;)

cin is an input buffer; cin.sync() has no defined meaning.

Strousrup doesn't quite agree with you, in 21.6.2 (third ed.): "Flushing
an istream is done using sync()."

Regards,

Zeppe

[James Kanze]

On Jul 20, 7:29 pm, Zeppe
<[e-mail] e:

James Kanze wrote:

On Jul 20, 12:03 am, Zeppe
<[e-mail] e:

Michele 'xjp' wrote:

yes, there is a \n in the buffer. Put cin.sync() after cin >scelta,
and everything will work ;)

cin is an input buffer; cin.sync() has no defined meaning.

Strousrup doesn't quite agree with you, in 21.6.2 (third ed.): "Flushing
an istream is done using sync()."

The standard says (for the effects of std::filebuf::sync):

If a put area exists, calls filebuf::overflow to write the
characters to the file. If a get area exists, the effect is
implementation-defined.

Given that the semantics of filebuf are defined in terms of
FILE*, by reference to the C standard, I would expect
std::filebuf::sync to have the same semantics as the C function
fflush (which is likely what Stroustrup is thinking of when he
wrote that). According to the C standard, the effects of
fflush( stream ) are:

If stream points to an output stream or an update stream in
which the most recent operation was not input, the fflush
function causes any unwritten data for that stream to be
delivered to the host environment to be written to the file;
otherwise, the behavior is undefined.

All of which is very logical when one considers the technical
meaning of the English word flush, which only applies to output.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Zeppe]

James Kanze wrote:

The standard says (for the effects of std::filebuf::sync):

If a put area exists, calls filebuf::overflow to write the
characters to the file. If a get area exists, the effect is
implementation-defined.

We are talking about the sync function in basic_istream.
For sync(), "my" standard says, at 27.6.1.3#36 (Unformatted input
functions):

Behaves as an unformatted input function (as described in 27.6.1.3,
paragraph 1), except that it does not count the number of characters
extracted and does not affect the value returned by subsequent calls to
gcount().

wrote that). According to the C standard, the effects of
fflush( stream ) are:

If stream points to an output stream or an update stream in
which the most recent operation was not input, the fflush
function causes any unwritten data for that stream to be
delivered to the host environment to be written to the file;
otherwise, the behavior is undefined.

All of which is very logical when one considers the technical
meaning of the English word flush, which only applies to output.

I know the semantics of fflush in C, and I agree that it's logical and
that it agrees to the English language, but I can't get your point:
fflush is one thing (and there is the corresponding flush method in C++
for ostreams), and sync is another thing (with a quite different English
meaning, too) :)

Regards,

Zeppe