while (std::cin >> value) - how does this work?
youknowme
while(std::cin >> value) is evaluated. It seems stationery like it does
not change!
I understand that the input operator >> has two operands: std::cin and
value - for this example lets suppose its an int value. How does the
condition get tested?
Alf P. Steinbach /Usenet
1. The expression 'std::cin >> value' performs an input operation. This
changes the state of the std::cin object. And possibly also of value.
2. The expression 'std::cin >> value' returns a reference to std::cin.
3. The reference is used in a context requiring a boolean value.
4. Therefore, it's conveted to void* via std::cin's member function
'operator void*', which is the closest thing to bool available.
5. 'operator void*' produces a void* pointer whose non-nullness reflects
the non-failure-state of the std::cin object. I.e., you get a pointer
that when converted to bool is 'true' if and only if '!cin.fail()'.
6. The void* pointer is implicitly converted to bool, to serve as while
continuation condition.
Cheers & hth.,
- Alf
--
blog at <url: http://alfps.wordpress.com>
Francis Glassborow
the input is successful. If the input operation fails for any reason
then the expression will evaluate as false.
So the code can be read as 'as long as input succeeds ...
Paul
news:ZbqdncYYIvJgHBfR...@bt.com...
http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.4
Francesco S. Carta
You have either misunderstood the FAQ or Francis' simple explanation,
because they both express the same correct concept.
--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
Paul
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c8ca651$0$6822$5fc...@news.tiscali.it...
As I said ... "Not Quite".
Pretty pedantic but I wasn't pushing that point , just posting the link.
HTH to clear up your misunderstanding :)
Francesco S. Carta
Sorry, I still don't get it. Could you please point out an example of
the case you depict? I might very well be missing some details and I'd
like to know them.
Paul
> Sorry, I still don't get it. Could you please point out an example of
> the case you depict? I might very well be missing some details and I'd
> like to know them.
>
Input type mismatch is one example. I hope this satisfies you,
youknowme
According to my book:
"When we use an istream as a condition, the effect is to test the state
of the stream. If the stream is valid - that is, if it is still possible
to read another input - then the test suceeds. An istream becomes invalid
when we hit end-of-file or encounter an invalid input, such as reading a
value that is not an integer. An istream that is an invalid state will
cause the condition to fail" (C++ Primer 4th Ed)
This means that a type mismatch will not give a 'true' result like you
believe. - I have ended my simple programs by intentially input a char,
rather than the expected int.
Francesco S. Carta
<recovering the context>
Absolutely not, because type mismatch is an input failure.
Please post an example where "Input can succeed but that expression
evaluate to false" (your words) and where "that expression" stands for
the expression within "while(std::cin >> value)" - from the context you
snipped, which I recovered.
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c8d11ca$0$30910$5fc...@news.tiscali.it...
It states on the link I posted, I quote:
<quote>
or if the actual info on the input stream isn't valid for the type of foo
(e.g., if foo is an int and the data is an 'x' character), the stream will
go into a failed state and the cast operator will return NULL.
</quote>
The input to the stream is successful but the expression evaluates to false
because the rhs operand is the wrong data type, or the input is wrong type ,
depends how you look at it. Maybe I am missing something but that seems
like an obvious and quite reasonable interpretation of the text.
news.virginmedia.com
"youknowme" <notv...@notvalid.net> wrote in message
news:i6j26h$gt6$2...@news.eternal-september.org...
Noooo I don't believe that type mismatch would evaluate to true, that's not
what I said . Other way around I said it would be false. I was just going
with what I read, see other post on this thread.
Alf P. Steinbach /Usenet
>
>>
> It states on the link I posted, I quote:
> <quote>
> or if the actual info on the input stream isn't valid for the type of foo (e.g.,
> if foo is an int and the data is an 'x' character), the stream will go into a
> failed state and the cast operator will return NULL.
> </quote>
>
> The input to the stream is successful but the expression evaluates to false
> because the rhs operand is the wrong data type, or the input is wrong type ,
> depends how you look at it. Maybe I am missing something but that seems like an
> obvious and quite reasonable interpretation of the text.
Dunno what this is about, but assuming that your quote is accurate, the text
you're quoting is just plain wrong.
Cheers,
Paul
"Alf P. Steinbach /Usenet" <alf.p.stein...@gmail.com> wrote in
message news:i6j7q4$odj$1...@news.eternal-september.org...
make such a negative statement about something you dunno about? I think you
will find that the text is correct and you are the one that is wrong.
Alf P. Steinbach /Usenet
If you're not here to learn, shut up.
Cheers & hth.,
- ALf
news.virginmedia.com
"Alf P. Steinbach /Usenet" <alf.p.stein...@gmail.com> wrote in
message news:i6jbga$j0p$1...@news.eternal-september.org...
nasty little pig ain't you
Francesco S. Carta
No, your interpretation of that FAQ is not reasonable at all.
If the input is not right for the type asked to std::cin then the input
fails and the expression evaluates as false, period.
Just learn to admit when you're wrong, otherwise, _prove_ that you're
right by posting the appropriate code and I will thank you for having
taught me something new.
Francis Glassborow
Maybe he is having difficulty understanding English. The return value
from operator>> when applied to a stream object has little to do with
the way that data gets into the input stream but a lot to do with its
extraction (it is an extraction operator as opposed to an insertion
operator)
If there is no data waiting for extraction and the stream is not in an
eof condition nor in a failed condition then the process will wait for
data. operator>> evaluates as false whenever it fails to write a value
into its right-hand argument. It is the successful writing of a value
that keeps it in a usable (true) state.
An istream object evaluates as true as long as its most recent use
successfully extracted data that satisfied the requirements of the right
operand.
Alf P. Steinbach /Usenet
Hm, I find it amazing that so much clarification has been needed for my original
answer (top of thread).
But just to dot the t's and square the i's, the FAQ's formulation is misleading
for the in-practice, and wrong (asserting a guarantee that isn't there) for the
ultra-formal.
Misleading: "info on the input stream" can be e.g. "3.14", which isn't valid for
int, but an instream will happily extract the "3" because that initial one
character subsequence is valid. Worse, for a double argument the info can be
European "3,14" and again, if the locale hasn't been properly set, the "3" is
extracted. So it's not about "the info" being valid for "the type", it's about
"the first non-whitespace character(s)" being a valid value specification for
"the type & locale".
Misleading in the non-quoted portion: talking about "good" state is ungood,
because stream.good() is not equivalent to !stream.fail().
The void* conversion is defined only in terms of fail(), not in terms of good().
So, I think Marshall-man oversimplified here, especially about "good" state.
For the ultra-formal the whole C++ iostream formatted input thing is just not
well-defined, because it's defined in terms fscanf (if I recall correctly, or
anyway in that family) which causes UB in certain cases...
Cheers,
news.virginmedia.com
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:BbOdne4DF65lWhDR...@bt.com...
Its simple:
a) Input succeeeds
b) std::cin>> fails
I don't know why you have a problem grasping this or if you are just trying
to twist the truth and twist words to fabricate some kind of debate to
support ignorance.
EOF.
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c8d7453$0$6838$5fc...@news.tiscali.it...
That is what I just said!
>
> Just learn to admit when you're wrong, otherwise, _prove_ that you're
> right by posting the appropriate code and I will thank you for having
> taught me something new.
>
What am I supposed to be wrong about here? You just agreed with what I said,
but you said it in a way as though you were disagreeing with me.
If there is no input there is no point in discussing the comparison
expression because nothing to compare, right? So lets assume input is always
successful.
Now you just agreed with me that if types are wrong the expression will
fail, right?
So where do you disagree with me?
Francesco S. Carta
Nope. Your original quote is "Input can succeed but that expression
evaluate to false". Notice the difference between your "input can
succeed" and my "input fails".
>>
>> Just learn to admit when you're wrong, otherwise, _prove_ that you're
>> right by posting the appropriate code and I will thank you for having
>> taught me something new.
>>
> What am I supposed to be wrong about here? You just agreed with what I
> said, but you said it in a way as though you were disagreeing with me.
Nope, I just said it in a correct way, while yours was incorrect.
The problem is that you're assigning the concept of "successful input"
to std::cin getting the data, which is wrong.
In simple terms, a successful input is the process of extracting the
correct data to a variable of the appropriate type, anything else is an
input failure, regardless of std::cin having pending data or not.
Try this program and tell me if you get the point now:
#include <iostream>
using namespace std;
int main() {
cout << "Enter a number or a letter:" << endl;
int i = 0;
if(cin >> i) {
cout << "Successful input from cin to int: " << i << endl;
} else {
cout << "Failed to read an int from cin" << endl;
cin.clear();
char ch = 0;
if(cin >> ch) {
cout << "Successful input from cin to char: " << ch << endl;
}
}
}
> If there is no input there is no point in discussing the comparison
> expression because nothing to compare, right? So lets assume input is
> always successful.
> Now you just agreed with me that if types are wrong the expression will
> fail, right?
> So where do you disagree with me?
If you rephrase your original sentence to match the reality of facts
then there will be no disagreement - but then, you'd have to retract the
"not quite true" you posted in reply to Francis' post.
news.virginmedia.com
>
> The problem is that you're assigning the concept of "successful input" to
> std::cin getting the data, which is wrong.
>
> In simple terms, a successful input is the process of extracting the
> correct data to a variable of the appropriate type, anything else is an
> input failure, regardless of std::cin having pending data or not.
>
>> If there is no input there is no point in discussing the comparison
>> expression because nothing to compare, right? So lets assume input is
>> always successful.
>> Now you just agreed with me that if types are wrong the expression will
>> fail, right?
>> So where do you disagree with me?
>
> If you rephrase your original sentence to match the reality of facts then
> there will be no disagreement - but then, you'd have to retract the "not
> quite true" you posted in reply to Francis' post.
>
I think of input as a buffer getting loaded with data from user or disk etc,
and it stops there. Assigning to variables is not input to me.
This is why I said "not quite true" as what Francis said was not quite true
according to my idea of input. But it was more or less good enough for the
discussion and I meant not to put Francis' post down in any way, if it
seemed like that, as I respect his knowledge. All I was really doing was
posting the link as further information on the subject.
HTH
Francesco S. Carta
All right, your position is clear now.
In the given context (input from cin to a variable), Francis'
explanation is flawless in my opinion, it's you that extended the given
context and shifted it to "input from external device to cin", thus
artificially making the original sentence incomplete (under your point
of view).
The next time you have to point out something, say it straight, don't
introduce it with an unjustified negative assertion about the
correctness of someone else's words.
Francesco S. Carta
You fail to fully express your position [the position being that you
speak about "input success" as the input step from the external device
to std::cin, while we speak specifically about the input step operated
by std::cin::operator>>() ] and furthermore you accuse him to support
ignorance. I think you owe him your apologies.
What should we think, that you support intellectual dishonesty by trying
to "win an argument" using a context shift?
Paul
like but don't state this as if it were an undisputed fact. I have not
extended the context it is you who has. You have extended the context of
input to also mean assigment to variable.
I did not state that input meant "input from an external device to cin",
Please do not misquote me.
>
> The next time you have to point out something, say it straight, don't
> introduce it with an unjustified negative assertion about the correctness
> of someone else's words.
>
I didn't point out anything(other than the fact the link gave a more
complete explanation) , say anything that could've been said more straight
or introduce anything with unjustified negative assertions about the
correctness of someone else's words.
You seem to have taken a very negative view to my post, all I did was
provide a link that enhanced and supported the previous posts. I don't see
what problem you have with that.
Francesco S. Carta
"while (std::cin >> value) - how does this work?"
The above is the subject which set the context for the discussion of
this thread. Quite evidently, we're speaking about inputting data from
std::cin to a variable.
> I did not state that input meant "input from an external device to cin",
> Please do not misquote me.
Sure, that was just a paraphrase. Let's use your words: "I think of
input as a buffer getting loaded with data from user or disk etc, and it
stops there." (this can be found just here above, in the quotes of this
very post)
>>
>> The next time you have to point out something, say it straight, don't
>> introduce it with an unjustified negative assertion about the
>> correctness of someone else's words.
>>
> I didn't point out anything(other than the fact the link gave a more
> complete explanation) , say anything that could've been said more
> straight or introduce anything with unjustified negative assertions
> about the correctness of someone else's words.
Francis posted a correct, simple explanation of how the "std::cin >>
value" expression evaluates, you replied "Not Quite true", let's recover
that, since you snipped it out:
Paul <pchr...@yahoo.co.uk>, on 12/09/2010 10:58:52, wrote:
> "Francis Glassborow" <francis.g...@btinternet.com> wrote in
>> Or to put it simply, std::cin >> value evaluates as true as long as
>> the input is successful. If the input operation fails for any reason
>> then the expression will evaluate as false.
>>
>> So the code can be read as 'as long as input succeeds ...
>>
> Not Quite true according to this :
> http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.4
>
People can decide by themselves whether that is "an unjustified negative
assertion about the correctness of someone else's words" or not.
> You seem to have taken a very negative view to my post, all I did was
> provide a link that enhanced and supported the previous posts. I don't
> see what problem you have with that.
I see no point in arguing any more with someone who fails to recognize
the evidence. Good luck.
Paul
collectively. I was a bit annoyed at the ignorance of someone elses posting
when they said something like.... dunno what its about but its just plain
wrong.. in ref to the FAQ's. I apologise.
>
> You fail to fully express your position [the position being that you speak
> about "input success" as the input step from the external device to
> std::cin, while we speak specifically about the input step operated by
> std::cin::operator>>() ] and furthermore you accuse him to support
> ignorance. I think you owe him your apologies.
This seems to be the problem as the function of the >> operator is not what
is meant by input. Well at least not in 99% of respected programming texts.
>
> What should we think, that you support intellectual dishonesty by trying
> to "win an argument" using a context shift?
Alf P. Steinbach /Usenet
>
> I did not intend this towards any individual meaning you as in you all
> collectively. I was a bit annoyed at the ignorance of someone elses posting when
> they said something like.... dunno what its about but its just plain wrong.. in
> ref to the FAQ's. I apologise.
Goodie.
I believe you're referring to my posting, where you adviced me to read the
thread from the top.
If you had done so yourself, then you would have found my original answer to the
OP at the top of the thread, and I believe that explanation is correct.
The words I used about the FAQ item were far too strong, though. The FAQ item is
not plain wrong, just a bit misleading (and for the ultra-formal wrong, but who
cares), as I've expanded on else-thread. The nice thing about the FAQ, though,
is that Marshall generally fixes things, if it's important enough.
But I don't think this is important enough to bother him. :-)
Cheers & hth.,
Francesco S. Carta
Should that make we feel better? You just extended the accusation to all
of us - let's limit the "all of us" to the people who posted in this thread.
>> You fail to fully express your position [the position being that you
>> speak about "input success" as the input step from the external device
>> to std::cin, while we speak specifically about the input step operated
>> by std::cin::operator>>() ] and furthermore you accuse him to support
>> ignorance. I think you owe him your apologies.
> You say "we" speak of input as being the step operated by the >>
> operator. This seems to be the problem as the function of the >>
> operator is not what is meant by input. Well at least not in 99% of
> respected programming texts.
"we" stands for the reasonable people that posted in this thread
recognizing its context.
About the "respected" programming texts, it's quite common to refer to
operator>>() as the "input operator" or the "extracting operator".
Let's stick to reality and avoid pulling numbers out of thin air.
>>
>> What should we think, that you support intellectual dishonesty by
>> trying to "win an argument" using a context shift?
> See other post;;.
Yep, go read my reply there. This is going to be my last reply to your
posts unless you become somewhat reasonable.
Paul
Where is the evidence that the varaible assignment is "input"?
It's pedantic yes but it's you're argument , if you want to nitpick over
words get it right.
This is not evidence to support this aspect of your argument.
>
>> I did not state that input meant "input from an external device to cin",
>> Please do not misquote me.
>
> Sure, that was just a paraphrase. Let's use your words: "I think of input
> as a buffer getting loaded with data from user or disk etc, and it stops
> there." (this can be found just here above, in the quotes of this very
> post)
Sarcasm now?
You are implying that what I said is the same as stating input means "input
from an external device to cin", LOL And you try to accuse me of changing
context of words.
>
>>>
>>> The next time you have to point out something, say it straight, don't
>>> introduce it with an unjustified negative assertion about the
>>> correctness of someone else's words.
>>>
>> I didn't point out anything(other than the fact the link gave a more
>> complete explanation) , say anything that could've been said more
>> straight or introduce anything with unjustified negative assertions
>> about the correctness of someone else's words.
>
> Francis posted a correct, simple explanation of how the "std::cin >>
> value" expression evaluates, you replied "Not Quite true", let's recover
> that, since you snipped it out:
No I said " not quite true according to this : LINK
Again twisted version of my words, or shall we say you snipped it :)
>
> Paul <pchr...@yahoo.co.uk>, on 12/09/2010 10:58:52, wrote:
> > "Francis Glassborow" <francis.g...@btinternet.com> wrote in
> >> Or to put it simply, std::cin >> value evaluates as true as long as
> >> the input is successful. If the input operation fails for any reason
> >> then the expression will evaluate as false.
> >>
> >> So the code can be read as 'as long as input succeeds ...
> >>
> > Not Quite true according to this :
> > http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.4
Glad you posted the uncut version again :)
> >
>
> People can decide by themselves whether that is "an unjustified negative
> assertion about the correctness of someone else's words" or not.
Why would anyone think its a negative assertion?
a) it asserts nothing
b) the link i posted supports what he said
c) It's blatently obviouswe what Francis meant by saying "the code can be
read as ". I hope you are not suggesting that I have tried to debate this.
d) It seems to be only you that's implying I have said something negative
towards francis.
Christ its just a tongue in cheek way of saying .. here's a good link on
this subject. I think you are a bit OTT saying I have made an "unjustified
negative
assertion about the correctness of someone else's words".
>> You seem to have taken a very negative view to my post, all I did was
>> provide a link that enhanced and supported the previous posts. I don't
>> see what problem you have with that.
>
> I see no point in arguing any more with someone who fails to recognize the
> evidence. Good luck.
Evidence of what, huh?
Good luck to you too, and happy coding. :)
Paul
>>> You fail to fully express your position [the position being that you
>>> speak about "input success" as the input step from the external device
>>> to std::cin, while we speak specifically about the input step operated
>>> by std::cin::operator>>() ] and furthermore you accuse him to support
>>> ignorance. I think you owe him your apologies.
>> You say "we" speak of input as being the step operated by the >>
>> operator. This seems to be the problem as the function of the >>
>> operator is not what is meant by input. Well at least not in 99% of
>> respected programming texts.
>
> "we" stands for the reasonable people that posted in this thread
> recognizing its context.
Reasonable people?
>
> About the "respected" programming texts, it's quite common to refer to
> operator>>() as the "input operator" or the "extracting operator".
>
Is it? funny that my google results dont agree
Extraction operator yes, but extraction is almost opposite to input
Maybe you are confused with the insertion operator <<
> Let's stick to reality and avoid pulling numbers out of thin air.
And this refers to?
>
>>>
>>> What should we think, that you support intellectual dishonesty by
>>> trying to "win an argument" using a context shift?
>> See other post;;.
>
> Yep, go read my reply there. This is going to be my last reply to your
> posts unless you become somewhat reasonable.
Already replied to it , I hope you see it as closure :)
Paul
>* Paul, on 13.09.2010 23:52:
>>
>> I did not intend this towards any individual meaning you as in you all
>> collectively. I was a bit annoyed at the ignorance of someone elses
>> posting when
>> they said something like.... dunno what its about but its just plain
>> wrong.. in
>> ref to the FAQ's. I apologise.
>
> Goodie.
>
> I believe you're referring to my posting, where you adviced me to read the
> thread from the top.
>
> If you had done so yourself, then you would have found my original answer
> to the OP at the top of the thread, and I believe that explanation is
> correct.
>
> The words I used about the FAQ item were far too strong, though. The FAQ
> item is not plain wrong, just a bit misleading (and for the ultra-formal
> wrong, but who cares), as I've expanded on else-thread. The nice thing
> about the FAQ, though, is that Marshall generally fixes things, if it's
> important enough.
>
and inform him of error.
> But I don't think this is important enough to bother him. :-)
>
I think its quite important if he is teaching people something that is "just
plain wrong". Is it really so unimportant he wont bother, or is he too
important for you to bother him.
Francis Glassborow
>>> You seem to have taken a very negative view to my post, all I did was
>>> provide a link that enhanced and supported the previous posts. I don't
>>> see what problem you have with that.
>>
>> I see no point in arguing any more with someone who fails to recognize
>> the evidence. Good luck.
> Evidence of what, huh?
> Good luck to you too, and happy coding. :)
>
I think what you did and what you seem to think you did are not the same
thing. However this thread is getting far too hot without any useful
light being shed. If you want to help others learn you are very welcome
here, if you want to be argumentative you soon won't be.
We all get things wrong from time to time, the best thing is to just
admit it and move on. The second best thing is to just drop the subject.
The worst thing is to try to argue that black (or some shade of grey) is
white.
You did not provide a link that enhanced other posts, you claimed to be
posting a link that would make it clear that what I had posted was wrong
if only slightly.
Paul
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:i_2dnTt6vquSLBPR...@bt.com...
You said in an earlier post that perhaps I don't understand English but
infact I know 3 languages, but there is only 1 with which I know the banter.
I think perhaps you people do not understand that to say something is not
quite true , esp in a tongue and cheek way, is completely different to
claiming it to be clearly wrong. And given the non English names of the
chosen few I think it is probably the case that they do not fully understand
English
Seems like a select few know-it-alls on this discussion forum have nothing
better to do than try to support their own overblown egos with the twisted
misinterpretations of other peoples posts.
I don't care if I am welcome here or not.
Good Luck.
Alf P. Steinbach /Usenet
No, it's just that as I said I used too strong a description (except for the
ultra-formal it isn't really "just plain wrong", just a teeny tiny little bit
misleading), and Marshall has been in and out of hospital the last years, so it
would have to be more important for me to bother him to fix up the FAQ.
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c8d11ca$0$30910$5fc...@news.tiscali.it...
> Paul <pchr...@yahoo.co.uk>, on 12/09/2010 17:38:52, wrote:
>
> <recovering the context>
>
>> Francesco S. Carta <entu...@gmail.com>, on 12/09/2010 18:25:04, wrote:
>>
>>> Paul <pchr...@yahoo.co.uk>, on 12/09/2010 17:14:51, wrote:
>>>
>>>>
>>>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>>>> news:4c8ca651$0$6822$5fc...@news.tiscali.it...
>>>>> Paul <pchr...@yahoo.co.uk>, on 12/09/2010 10:58:52, wrote:
>>>>>
>>>>>> "Francis Glassborow" <francis.g...@btinternet.com> wrote in
>>>>>>> Or to put it simply, std::cin >> value evaluates as true as long as
>>>>>>> the input is successful. If the input operation fails for any reason
>>>>>>> then the expression will evaluate as false.
>>>>>>>
>>>>>>> So the code can be read as 'as long as input succeeds ...
>>>>>>>
>>>>>> Not Quite true according to this :
>>>>>> http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.4
>>>>>
>>>>> You have either misunderstood the FAQ or Francis' simple explanation,
>>>>> because they both express the same correct concept.
>>>>>
>>>> Input can succeed but that expression evaluate to false.
>>>> As I said ... "Not Quite".
>>>> Pretty pedantic but I wasn't pushing that point , just posting the
>>>> link.
>>>> HTH to clear up your misunderstanding :)
>>>
>>> Sorry, I still don't get it. Could you please point out an example of
>>> the case you depict? I might very well be missing some details and I'd
>>> like to know them.
>>>
> >
> > Input type mismatch is one example. I hope this satisfies you,
>
> Absolutely not, because type mismatch is an input failure.
>
> Please post an example where "Input can succeed but that expression
> evaluate to false" (your words) and where "that expression" stands for the
> expression within "while(std::cin >> value)" - from the context you
> snipped, which I recovered.
>
> --
#include <iostream>
using namespace std;
int main()
{
int x;
cout << "Enter char from a to z:";
cin >> x;
while (x < 1 || x > 9)
{
cin >> x;
if (cin.fail())
{
cout<< "cin>>x failed!"<<endl;
cin.clear();
char c = cin.get();
cout<< "Your input was \'" << c << " \'. If this is true then input was
processed by this program." <<endl;
cout << "Try again:" << endl;
}
}
cout << "Program ending.... " << endl;
}
The extraction operator extracts data from a stream to another object. It
is the success of this operation that we are testing for with the expression
(cin>>x).
If you think we are testing for program input then
Good Luck , you'll need it.
Francis Glassborow
>
>
> "Francesco S. Carta" <entu...@gmail.com> wrote in message
I do not understand what you think that program will prove. I think this
whole thread has become hopelessly confused.
Francesco S. Carta
14:00:00, wrote:
This thread has been /brought/ to confusion, and any attempt to
straighten it out has been counter-balanced with further confusion.
I'll give another try.
Input and output are two concepts related to the direction of a data flow.
When speaking about a program as a whole, "input" means bringing data
from the outside of the program to its inside - in the end, this means
bringing the data into an appropriate variable, where we can /use/ it.
Conversely, and still speaking about a program as a whole, "output"
means bringing the data from a variable to anything outside of the
program (e.g. to the screen or to a file).
Strictly speaking, the concept of input (or output) has no meaning until
we associate it to appropriate entities, which represent the source and
the destination of a data flow.
source --> destination
from the source point of view, the "-->" flow is "output"
from the destination point of view, the "-->" flow is "input"
Under the above strict meaning, the generic process of inputting data
into a program passes through several steps, where the data gets
outputted and inputted by several couples of entities.
In this specific, simple and practical example:
user --> keyboard --> keyboard driver --> operating system --> std::cin
--> variable
all of the "-->" flows represent an input or an output depending on the
point of view: on the left side of a "-->" we have a source that
produces an output, on the right side of a "-->" we have a destination
that receives an input.
Now, the context of this thread was crystal clear from the start: we are
speaking of the last step of the input process, the passage from
std::cin to a variable.
Francis, your post was correct under both "points of view":
- the specific one, where we speak about the very last passage;
- the generic one, where we speak about "input" as the whole process of
getting the data from the user to a variable within a program, where we
can use the data;
In both cases, if "cin >> variable" evaluates as false, we have an input
failure. It doesn't matter whether, say, 99 out of 100 steps of the
process were successful: we can't use the inputted data because one of
the steps failed.
All the confusion arose from Paul's posts, who repeatedly tried to shift
the context and limit the concept of "successful input" to std::cin
getting the data - which would be the just the 98th step of our
hypothetical 100 steps input process.
I'm not very confident that Paul will accept and publicly admit this,
but I'm really confident that anybody else will recognize the things as
they are, despite of the fact that I'm not a native English speaker and
that my understanding of the English language has been questioned.
news.virginmedia.com
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:pNOdnb4epdAiXg3R...@bt.com...
The program proves that input was successful although (cin>>x) was false
I think it also proves that statements such as "type mismatch is an input
failure" are complete nonsense.
Good Luck
Francis Glassborow
meant so having your own interpretation gains nothing except sowing
confusion in the minds of people such as the OP.
Alf P. Steinbach /Usenet
>
> The program proves that input was successful although (cin>>x) was false
> I think it also proves that statements such as "type mismatch is an input
> failure" are complete nonsense.
It's difficult to see exactly what you disagree with or don't understand.
In the end, if you don't trust the advice you get here, the C++ standard is the
final arbiter.
You can download the latest C++0x draft (I think it's N3092) for free from the
committee pages; I just type "C++ committee" in the Firefox address box and it
lands me there.
Alf P. Steinbach /Usenet
Uh, I've had that argument made against me, by a mob of
programming-language-religious-minded insectoids.
And recently, discussing Gabriel's DR about aliasing, over in clc++, I had that
thrown in my face again, but then just by a single person (one who isn't
generally religious, but evidently had been swayed by a little too much FUD).
It's not really a valid argument.
A mob can be wrongo, completely.
Consider, for example, that some ~90% of the US population say that they believe
that they're in telepathic communication with an invisible alien in outer space,
every night (or at least every week). Clearly, as I see it, no matter how much
they assert that I'm the one who is out of step, those of them who are not lying
about what they think, are seriously deluded. And as it happens, our Norwegian
princess Märtha Louise believes that she can talk with angels and the dead, and
of course also animals, and our minister of health believes in healing via
telephone, it cured my son, he claims; in a society where people either are
idiots or claim to be deluded in order to gain social advantage, I think being
out of step is not only possibly right, but honorable.
Cheers,
Francis Glassborow
step is not necessarily bad but it should be read in context. In this
case I think most of us would agree that it is just sowing confusion.
I am not sure that those who regularly contribute here will appreciate
being characterised as a mob or worse.
It is time to stop this thread as it seems to have degenerated to the
point of pointlessness.
Alf P. Steinbach /Usenet
Oh, I wasn't implying that our Norwegian princess or (would that be former? not
sure) health minister are possibly right. I think for the princess it's a case
of genuine delusion coupled with business interests -- always a very forceful
combination. And for the minister of health I believe it was a matter of
supporting his wife, who evidently suffered from the delusion that he expressed
a belief in, and if so then he behaved very honorably but also foolishly.
> In this case I think most
> of us would agree that it is just sowing confusion.
Yes.
My point was just that requiring /conformance/ is counter-productive as a means
to reduce confusion.
The "don't go out of step" meme is in my view dangerous, and should not be
invoked for any purpose.
I tried to illustrate how badly things can turn out when people conform too
much. You get religious fanaticism like in the USA and Iran, for example. Their
conformance to what they perceive to be society's norms and beliefs, doesn't
reduce their confusion, at all, and may just start a war in the Middle East.
Of course, I could have mentioned how Hitler and the Nazis always marched in
step, but then I would have been invoking Godwin's law.
> I am not sure that those who regularly contribute here will appreciate being
> characterised as a mob or worse.
Well, I'm a regular contributor.
On and off.
You're probably not realizing it, but you're now for the second time calling
upon a reader's wish to belong in a social group (of which you make yourself a
member, and the other, not). To news at virginmedia (hey, doesn't Dom De Vitto
work there? :-) ) you say, don't walk out of step, i.e. try to belong to the
group. To me you say don't characterize the group you'd want to belong to. Well
I'm as much a member of that group as you, and if I chose to call us, or the
rest of us minus me, collectively insectoids or whatever, then you should first
of all pay attention, Francis, and secondly you should appreciate the feedback.
> It is time to stop this thread as it seems to have degenerated to the point of
> pointlessness.
That may be so. ;-)
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c90cd50$0$6839$5fc...@news.tiscali.it...
The above is not a "strict meaning" of input and output
>
> In this specific, simple and practical example:
>
> user --> keyboard --> keyboard driver --> operating system -->
> std::cin --> variable
>
> all of the "-->" flows represent an input or an output depending on the
> point of view: on the left side of a "-->" we have a source that produces
> an output, on the right side of a "-->" we have a destination that
> receives an input.
Applying your theory to ( cin>>object) we have:
OS --> cin --> object.
Here the assignment to the object is output., or more accurately called
extraction. The fact that you call this input is bewildering.
Nice, your own theory proves you wrong.
>
> Now, the context of this thread was crystal clear from the start: we are
> speaking of the last step of the input process, the passage from std::cin
> to a variable.
No we were talking about the expression (cin>>object) , not just the
assignment to variable.
>
> Francis, your post was correct under both "points of view":
>
> - the specific one, where we speak about the very last passage;
>
> - the generic one, where we speak about "input" as the whole process of
> getting the data from the user to a variable within a program, where we
> can use the data;
>
> In both cases, if "cin >> variable" evaluates as false, we have an input
> failure. It doesn't matter whether, say, 99 out of 100 steps of the
> process were successful: we can't use the inputted data because one of the
> steps failed.
But my program demonstrates input success. So you got anything to wangle
your way out of that?
>
> All the confusion arose from Paul's posts, who repeatedly tried to shift
> the context and limit the concept of "successful input" to std::cin
> getting the data - which would be the just the 98th step of our
> hypothetical 100 steps input process.
It is you who is shifting the context of input,
>
> I'm not very confident that Paul will accept and publicly admit this, but
> I'm really confident that anybody else will recognize the things as they
> are, despite of the fact that I'm not a native English speaker and that my
> understanding of the English language has been questioned.
>
Too right I don't accept it because its total nonsense. LOL
You obviously actually think you are right , I'm dumfounded .
Your lack of understanding of English is perhaps why you started this
argument in the first place.
Lets me explain:
Francis stated.... "So the code can be read as 'as long as input succeeds
...".
This is his opinion and in the context it cannot be asserted as correct or
incorrect, I trust you can understand this.
My remark towards his opinion was an expression of my own opinion. You
constructed an argument and try to imply that I have disputed some fact that
Francis put forward.
Why did he said "the code can be read as". Probably because he knows its
would be wrong to state that the expression strictly means successful input.
It seems that your side of the argument is what Francis clearly thought was
not completely true in the first place, because he would not have said "the
code can be read as" otherwise.
GL
Francesco S. Carta
> succeeds ....".
> This is his opinion and in the context it cannot be asserted as correct
> or incorrect, I trust you can understand this.
> My remark towards his opinion was an expression of my own opinion. You
> constructed an argument and try to imply that I have disputed some fact
> that Francis put forward.
>
> Why did he said "the code can be read as". Probably because he knows its
> would be wrong to state that the expression strictly means successful
> input.
> It seems that your side of the argument is what Francis clearly thought
> was not completely true in the first place, because he would not have
> said "the code can be read as" otherwise.
First of all, you cannot question my understanding of the English
language: it would be curious to let a native English language teacher
analyze all of our posts and point out the various spelling, grammar and
syntax errors, just to see who has got it better or worse. But let's put
this apart: scripta manent.
You questioned more than once my usage of the word "input" associated to
the extractor operator. It's clear that such an association is shared
among many posters in this group and as well - and more importantly - it
is shared by the C++ standard itself:
<citation>
27.6.1.2.2 Arithmetic Extractors [lib.istream.formatted.arithmetic]
operator>>(short& val);
operator>>(unsigned short& val);
operator>>(int& val);
operator>>(unsigned int& val);
operator>>(long& val);
operator>>(unsigned long& val);
operator>>(float& val);
operator>>(double& val);
operator>>(long double& val);
operator>>(bool& val);
operator>>(void*& val);
As in the case of the inserters, these extractors depend on the locale€s
num_get<> (22.2.2.1) object to perform parsing the input stream data.
These extractors behave as formatted input functions (as described in
27.6.1.2.1).
</citation>
Since they behave as formatted input functions, it is correct to say
that the process of extracting data from std::cin to an object is an
input process, and since this process can succeed or fail, it is correct
to use the sentence "as long as input succeeds" attributing it to this
extraction, which is what Francis meant and which is what any reasonable
person would understand from the context of the thread up to his message.
Now, after he posted that message, you replied "Not Quite true according
to this:" and you linked a FAQ.
You've changed your own interpretation of that sentence: when I first
questioned your understanding of his sentence, you replied with this:
> Input can succeed but that expression evaluate to false.
> As I said ... "Not Quite".
> Pretty pedantic but I wasn't pushing that point , just posting the link.
That is, you confirmed that yours was a technical correction (and even
if you wrote that you weren't pushing that point, nonetheless you
expressed it).
Then you said that it was a "tongue in cheek" sentence that wasn't meant
to "correct" Francis' words, /but/ you went to great lengths to prove
that /your/ interpretation of the word "input" was the correct one,
while I've struggled to make clear that the word "input" changes its
meaning depending on the context in which it is used, and that the
meaning he used in /this context/ was the obvious one - furthermore as
the Standard explicitly tells that an extractor behaves as an input
function.
Let's see how you try to correct the C++ Standard itself or as you
change your interpretation of your very sentences, once more.
news.virginmedia.com
Look Fool
We were a discussing a process that accepts input from the keyboard into a
program. Given this context the term "input" means input to the stream, or
into the program. It most certainly does not mean assignment to objects
within the program.
And you're misinterpretation of the standards won't help you.
Francesco S. Carta
Ahuahauahauhaa, happy ending! :-)
Francis Glassborow
Actually at the time that the extraction operator is evaluated we have
no knowledge as to how and when the data got into std::cin. It may
simply be sitting there left over from some earlier operation (this is
quite often a cause of failure.
news.virginmedia.com
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:67mdnX-ZiJIWyQzR...@bt.com...
Actually it has been proven you know very little about it, and Francesco
even less.
Please stop replying to my posts with your twisted use of language. you have
both been PROVEN wrong and until you accept that fact STFU.
news.virginmedia.com
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:67mdnX-ZiJIWyQzR...@bt.com...
All I can say regarding this is...
Fuckin twisted idiots!