Formatting stream input.

[BigMan]

How does one rewrite the following piece of code using std::cin?

int n;
scanf( "n=%d", &n );

[Victor Bazarov]

BigMan wrote:

How does one rewrite the following piece of code using std::cin?

int n;
scanf( "n=%d", &n );

Something like

char enn, eqsign;
std::cin >> enn >> eqsign >> n;

V

[Evan]

Depends on how closely you want the behavior to match. This is as close
to the behavior as I can get:

char prefix[2];
cin.get(&prefix[0], 3);
if(strcmp(prefix,"n=") == 0)
cin >> n;
else
cin >> dummy;

This reads in two characters, makes sure they are n=, then reads in n.
If the first two characters aren't n=, it leaves n untouched and reads
the next input into a dummy variable. I'm not sure what scanf does in
these cases though, whether it leaves n untouched or puts crap in it,
so don't know if it's the same.

Victor's won't have exactly the same behavior in exceptional conditions
because stuff like "n = 4", which won't work with scanf, will. Whether
this is acceptable or desirable is up to you of course, but it is
different.

[Victor Bazarov]

Evan wrote:

Depends on how closely you want the behavior to match. This is as
close to the behavior as I can get:

char prefix[2];
cin.get(&prefix[0], 3);
I think '3' is either a typo or a serious mistake.
if(strcmp(prefix,"n=") == 0)
cin >> n;
else
cin >> dummy;

This reads in two characters, makes sure they are n=, then reads in n.
If the first two characters aren't n=, it leaves n untouched and reads
the next input into a dummy variable. I'm not sure what scanf does in
these cases though, whether it leaves n untouched or puts crap in it,
so don't know if it's the same.

Victor's won't have exactly the same behavior in exceptional
conditions because stuff like "n = 4", which won't work with scanf,
will. Whether this is acceptable or desirable is up to you of course,
but it is different.

[Marc Aguilera]

"BigMan" <Bi****@abv.bg> wrote in message news:<11*********************@o13g2000cwo.googlegr oups.com>...

How does one rewrite the following piece of code using std::cin?

int n;
scanf( "n=%d", &n );

Hey man! IGNORE THE PREVIOUS POST (mad) !!!!! IT actually SUCKs for
NOTHING-ness.(Sound like my arse)
Something like this:

int n;
std::cout<<"n=";
std::cin>>n;

Just that!

[Evan]

> I think '3' is either a typo or a serious mistake.

Ah, it's a serious mistake. Though actually it's the 2 that is the
dimensions of the prefix array that is wrong, not the 3 in get.

I didn't think about the null termination character that get adds at
the end and only gave space for the 'n' and '=' characters. Turning on
MSVC's stack frame checking showed that the get call was stomping over
other parts of the stack; changing the dimension to 3 fixed it.

Corrected code is as follows:

char prefix[3];
cin.get(&prefix[0], 3);

Thanks for the correction.

(You know, when my subconscious goes "that's not right -- why are the
numbers different", I really ought to look into it more...)

[Victor Bazarov]

Evan wrote:

I think '3' is either a typo or a serious mistake.
Ah, it's a serious mistake. Though actually it's the 2 that is the
dimensions of the prefix array that is wrong, not the 3 in get.

I didn't think about the null termination character that get adds at
the end and only gave space for the 'n' and '=' characters.

Are you sure 'get' adds anything?
Turning on
MSVC's stack frame checking showed that the get call was stomping over
other parts of the stack; changing the dimension to 3 fixed it.

Corrected code is as follows:

char prefix[3];
cin.get(&prefix[0], 3);

Thanks for the correction.
Actually I still think you should be only reading 2 characters from the
input stream. If you read 3, a subsequent read will be missing the leading
digit. I am too lazy to check now, but RTFM on istream::get.
(You know, when my subconscious goes "that's not right -- why are the
numbers different", I really ought to look into it more...)

That's not a bad idea.

V

[Evan]

> Actually I still think you should be only reading 2 characters from
the

input stream. If you read 3, a subsequent read will be missing the leading digit. I am too lazy to check now, but RTFM on istream::get.

get( buffer, count ) reads count-1 characters from the string, then
tags on a terminating 0.

"The three-argument s.get(p,n,term) reads at most n-1 characters into
p[0]..p[n-2]. A call of get() will always place a 0 at the end of the
characters (if any) it placed in p[], so p must point to an array of at
least n characters." (3rd edition of Strostrup, p. 618-619)

cin.read is available if you don't want the null termination added.

[Victor Bazarov]

Evan wrote:

Actually I still think you should be only reading 2 characters from
the input stream. If you read 3, a subsequent read will be missing
the leading digit. I am too lazy to check now, but RTFM on
istream::get.

get( buffer, count ) reads count-1 characters from the string, then
tags on a terminating 0.

"The three-argument s.get(p,n,term) reads at most n-1 characters into
p[0]..p[n-2]. A call of get() will always place a 0 at the end of the
characters (if any) it placed in p[], so p must point to an array of
at least n characters." (3rd edition of Strostrup, p. 618-619)

cin.read is available if you don't want the null termination added.

You're absolutely correct. I overcame my lazyness and looked it up in
the Standard. Lo and behold, count-1 characters are stored and the null
character is stuffed into the buffer. I must have confused it with the
'read' member. Rats! :-)