input to cin

[news.virginmedia.com]

Hello People,

I posted the code below to demonstrate the meaning of successful input with
regards std::cin. But I am having problems with a few people.
These people insist that the term "input" with regards to the " cin>>object"
expression means the stage where some value is assigned to object.
It is blatantly obvious to me that it is just complete nonsense, so am I
missing something or , as I suspect, are these people just idiotic
thickheads who don't give a dam about what is correct?

Here is some code I used to demonstrate a situation where:
a) Input is successful
b) boolean test on (cin>>object) fails.


#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;
}


I think this code demonstrates successful input , however these people argue
with what appears to be clear evidence.
I get really annoyed with thick people sometimes and extremely annoyed with
thick people who are also ignorant fucks. So please tell me if I'm missing
something obvious.
TY

 

[Ben Bacarisse]

Hello People,

I posted the code below to demonstrate the meaning of successful
input with regards std::cin. But I am having problems with a few
people.
These people insist that the term "input" with regards to the "
cin>>object" expression means the stage where some value is assigned
to object.
It is blatantly obvious to me that it is just complete nonsense, so am
I missing something or , as I suspect, are these people just idiotic
thickheads who don't give a dam about what is correct?

Here is some code I used to demonstrate a situation where:
a) Input is successful
b) boolean test on (cin>>object) fails.

#include <iostream>
using namespace std;

int main()
{
int x;
cout << "Enter char from a to z:";
cin >> x;
while (x < 1 || x > 9)

What's the purpose of this part? If the >> operation above fails (as it
will if user follows the instructions) then x is indeterminate and the
program has no well-defined meaning. I am not a C++ expert but that's
my reading of the 2003 standard.

If the point is that the user should ignore the instructions and enter a
valid number, then why bother with this part at all?

{
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;
}


I think this code demonstrates successful input , however these people
argue with what appears to be clear evidence.

I don't find it clear, in part because of my remark above but also
because there are several input operations and it's not clear which one
is there to make your point.

The point you seem to be making is that >> can fail whilst none the less
doing some input. The clearest example of that would be the case of
" X" being processed by cin >> x. The spaces will be consumed despite
the fact that the overall input operation fails. Most people would not
regard that as "successful input" but I don't see any point in trying
to talk you out of your usage.

If this is the point you are making than I think it a storm in a tea
cup. The remark you originally objected to was:

| 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.

and I don't see how your example relates to this simple description.
The phrases "the input" and "the input operation" clearly relate to
std::cin >> value as a whole.

By far the simplest solution would be for you to re-word that
description so that it becomes correct from you point of view. It would
then be clear what part of the description is really bothering you.

I get really annoyed with thick people sometimes and extremely annoyed
with thick people who are also ignorant fucks.

That fact that you don't seem to think that intelligent people can
disagree about what seem to you to be matters of fact gave me some
pause, but I thought answering might still serve some purpose. It is
quite clear to me from reading various groups that the people you are
referring to are neither stupid nor ignorant (about C++ at least --
everyone is ignorant about some things). You are free to be as annoyed
as you like with them, but stupidity entails more than disagreement
about something, no matter how clear-cut it seems to you.

So please tell me if
I'm missing something obvious.

I think you are missing the usual meaning of a successful input
operation but that seems rather too simple. Why not re-word Francis
Glassborow's description using your terminology so readers can see the
difference that bother you.

 

[news.virginmedia.com]

What's the purpose of this part? If the >> operation above fails (as it
will if user follows the instructions) then x is indeterminate and the
program has no well-defined meaning. I am not a C++ expert but that's
my reading of the 2003 standard.

This is not relevant part the code, it's just a condition to exit loop.

If the point is that the user should ignore the instructions and enter a
valid number, then why bother with this part at all?


I don't find it clear, in part because of my remark above but also
because there are several input operations and it's not clear which one
is there to make your point.

Ok perhaps that code is not too great, look at this simpler example:

#include <iostream>
using namespace std;

int main()
{
int x=0;
char c='\0';
cout << "Enter a char:";
cin>>x;
if(cin.fail()){
cout<< "cin>>x failed!"<<endl;
cin.clear(); //clear flags
c = cin.get(); //get whatever happens to be in the stream.
cout<< "The data obtained from cin is "<< c <<endl; //voila, the
data was input to the stream and processed by the program
}
}


This program demonstrates successful input to cin although the expression
cin>>x fails.
There is only one input operation here so it should be clearer.
If the input was unsuccessful I wouldn't be able to process it.

So lets say we wanted to extend the functionality and derive a class, maybe
implement our own >> function, how should we regard input?
In general lets look at this in the the given context, that is regarding C++
streams.

Should we regard input as..
a) data source ->input stream
or
b) input stream -> object
or
c) data source -> object (skip the stream part altogether )
or
d) switch the context when it suits.
or
e) neither of the above

I leave it for you to decide.

 

[Ike Naar]

Ok perhaps that code is not too great, look at this simpler example:

#include <iostream>
using namespace std;

int main()
{
int x=0;
char c='\0';
cout << "Enter a char:";
cin>>x;
if(cin.fail()){
cout<< "cin>>x failed!"<<endl;
cin.clear(); //clear flags
c = cin.get(); //get whatever happens to be in the stream.
cout<< "The data obtained from cin is "<< c <<endl; //voila, the
data was input to the stream and processed by the program
}
}


This program demonstrates successful input to cin although the expression
cin>>x fails.
There is only one input operation here so it should be clearer.
If the input was unsuccessful I wouldn't be able to process it.

Suppose we run the above program with the following input:

999999999999999999999999999a

The ``cin>>x'' statement will read the sequence of nines, but since the
value represented by it is too large for an int, the value cannot be stored
in x, and the ``cin>>x'' operation fails.

Then the ``cin.get()'' command will produce the character 'a', which is the
first character following the sequence of nines.

Now, if I follow correctly what you said, the program demonstrates successful
input of the sequence of nines to cin, but if we look in the stream we don't
find it there, we only find the 'a' that follows it.

Has the sequence of nines been successfully read?

 

[news.virginmedia.com]

Suppose we run the above program with the following input:

999999999999999999999999999a

The ``cin>>x'' statement will read the sequence of nines, but since the
value represented by it is too large for an int, the value cannot be
stored
in x, and the ``cin>>x'' operation fails.

Then the ``cin.get()'' command will produce the character 'a', which is
the
first character following the sequence of nines.

Now, if I follow correctly what you said, the program demonstrates
successful
input of the sequence of nines to cin, but if we look in the stream we
don't
find it there, we only find the 'a' that follows it.

Has the sequence of nines been successfully read?

The program is not designed to be unbreakable and only works for its
intended purpose if a char in input.
But interesting scenario , I will take a look at it.

 

[news.virginmedia.com]

If that's what you mean by "successful".


Actually, there are two input operations: operator>> and get().


It was unsuccessful and yet you could process something. Strange? No, it
merely indicates that the discussion is about terminology, not substance.


f) all of the above.

You don't make sense.

Plonk.

 

[Keith Thompson]

I think this code demonstrates successful input , however these people argue
with what appears to be clear evidence.
I get really annoyed with thick people sometimes and extremely annoyed with
thick people who are also ignorant fucks. So please tell me if I'm missing
something obvious.

You appear to be missing the ability to interact with others in a
civilized manner.

 

[news.virginmedia.com]

You appear to be missing the ability to interact with others in a
civilized manner.

You appear to be the type of person that thinks people who swear are
uncivilized. But then appearances can be misleading.

 

[Keith Thompson]

You appear to be the type of person that thinks people who swear are
uncivilized. But then appearances can be misleading.

It's more about your attitude than about the words you use to express it.

 

[news.virginmedia.com]

[snip]
I think this code demonstrates successful input , however these
people argue
with what appears to be clear evidence.
I get really annoyed with thick people sometimes and extremely
annoyed with
thick people who are also ignorant fucks. So please tell me if I'm
missing
something obvious.

You appear to be missing the ability to interact with others in a
civilized manner.

You appear to be the type of person that thinks people who swear are
uncivilized. But then appearances can be misleading.

It's more about your attitude than about the words you use to express it.

--

So because my attitude is "uncivilized" you refuse to comment on the given
conversation and try to lead the conversation off on a negative tangent
about my having an uncivilised attitude.
Aye whatever. You 're probably as brain dead as those ignorant fuckpigs I
referred to earlier
Go read the porn spam or something dude.

 

[news.virginmedia.com]

Keith Thompson ha scritto:


I agree. Else-thread he plonked me just because my answer to his question
did "not make sense" to him. Software engineering is teamwork; calling his
colleagues "ignorant fucks" just because they don't agree on some
technical matters should have absolutely no place in this business (or any
other business, for that matter).

Who gives a toot if you agree or disagree. You are obviously a numbskull ,
get outta here if you have nothing constructive to say.
I plonked your post instantly because it was nothing more than idiotic
nonsense.

Plonk

 

[news.virginmedia.com]

What's the purpose of this part? If the >> operation above fails (as it
will if user follows the instructions) then x is indeterminate and the
program has no well-defined meaning. I am not a C++ expert but that's
my reading of the 2003 standard.

If the point is that the user should ignore the instructions and enter a
valid number, then why bother with this part at all?


I don't find it clear, in part because of my remark above but also
because there are several input operations and it's not clear which one
is there to make your point.

The point you seem to be making is that >> can fail whilst none the less
doing some input. The clearest example of that would be the case of
" X" being processed by cin >> x. The spaces will be consumed despite
the fact that the overall input operation fails. Most people would not
regard that as "successful input" but I don't see any point in trying
to talk you out of your usage.

If this is the point you are making than I think it a storm in a tea
cup. The remark you originally objected to was:

| 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.

and I don't see how your example relates to this simple description.
The phrases "the input" and "the input operation" clearly relate to
std::cin >> value as a whole.

By far the simplest solution would be for you to re-word that
description so that it becomes correct from you point of view. It would
then be clear what part of the description is really bothering you.


That fact that you don't seem to think that intelligent people can
disagree about what seem to you to be matters of fact gave me some
pause, but I thought answering might still serve some purpose. It is
quite clear to me from reading various groups that the people you are
referring to are neither stupid nor ignorant (about C++ at least --
everyone is ignorant about some things). You are free to be as annoyed
as you like with them, but stupidity entails more than disagreement
about something, no matter how clear-cut it seems to you.


I think you are missing the usual meaning of a successful input
operation but that seems rather too simple. Why not re-word Francis
Glassborow's description using your terminology so readers can see the
difference that bother you.

You seem to have a high regard for Francis Glassborow, so perhaps you will
accept the truth if it came from him?
FG made and opinion in such a way that it cannot be contradicted, by stating
"it can be read as" and he is also implying that it would not exactly be a
true definition.
Now if I was to disagree with him , well I can't disagree with him because
he has written his opinion in such a way that it is undisputable.
But ok lets say I disagree, what exactly am I saying is incorrect about what
he wrote? Am I implying he did not write the "it can be read as " bit and
twisting the truth to make out that he was giving his interpretation of a
definition?

Ok lets assume that Francis wrote that "the true definition of cin>>x is
successful input". And lets assume that I disagreed.
Who would be correct?
Obviously I would be correct for disagreeing with this very incorrect
definition of cin>>x.
But this not what happened.

Ok lets say I disagree with the fact that he thinks it can be read as
successful input, which is more or less what he wrote.
Yes I do disagree with that, so what! I don't read it as successful input,
whether he thinks it can be read as that or not.

So you see nothing bothers me about what FG wrote, but the problem is that
he and a few others have twisted the truth to imply that I have have
disagreed with some statement that Francis has given. In fact you(Ben)
actually imply this here too.
But because their/your argument is some twisted misinterpretation the focus
of the argument keeps changing and you don't really seem to know what you
are arguing about. You could make up a new argument every 2 minutes.

So it seems that the people arguing with me are arguing the case that cin>>x
means successful input, where I am arguing the case that this not exactly
true.
Given this twisted misconception, lets go for it, lets have the debate. I
don't mind because my side side of the argument is what I think to be
correct anyway.


So you got anything more to say or are you just gonna slither away into the
darkness, like those numbskulls Franceso S Carta and Francis Glasborow seem
to have done?

 

[Francesco S. Carta]

You seem to have a high regard for Francis Glassborow, so perhaps you
will accept the truth if it came from him?
FG made and opinion in such a way that it cannot be contradicted, by
stating "it can be read as" and he is also implying that it would not
exactly be a true definition.
Now if I was to disagree with him , well I can't disagree with him
because he has written his opinion in such a way that it is undisputable.
But ok lets say I disagree, what exactly am I saying is incorrect about
what he wrote? Am I implying he did not write the "it can be read as "
bit and twisting the truth to make out that he was giving his
interpretation of a definition?

Ok lets assume that Francis wrote that "the true definition of cin>>x is
successful input". And lets assume that I disagreed.
Who would be correct?
Obviously I would be correct for disagreeing with this very incorrect
definition of cin>>x.
But this not what happened.

Ok lets say I disagree with the fact that he thinks it can be read as
successful input, which is more or less what he wrote.
Yes I do disagree with that, so what! I don't read it as successful
input, whether he thinks it can be read as that or not.

So you see nothing bothers me about what FG wrote, but the problem is
that he and a few others have twisted the truth to imply that I have
have disagreed with some statement that Francis has given. In fact
you(Ben) actually imply this here too.
But because their/your argument is some twisted misinterpretation the
focus of the argument keeps changing and you don't really seem to know
what you are arguing about. You could make up a new argument every 2
minutes.

So it seems that the people arguing with me are arguing the case that
cin>>x means successful input, where I am arguing the case that this not
exactly true.
Given this twisted misconception, lets go for it, lets have the debate.
I don't mind because my side side of the argument is what I think to be
correct anyway.


So you got anything more to say or are you just gonna slither away into
the darkness, like those numbskulls Franceso S Carta and Francis
Glasborow seem to have done?

I would have kept away from this thread but since you directly call me
in by name I cannot resist.

Once more you show how the interpretation you make of your very
statements is stable as a skyscraper built on the sands... I must cite
again your very first reaction after my intervention in that thread:

> 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.
>

Once more, your very first reaction was to confirm the fact that you
were making a technical correction to Francis' words.

After several different posts where I've tried to explain that the
concept of "input" is relative to the involved entities and to the
context it is used in - and the context into which Francis used it was
perfectly fine - I finally decided to cite the C++ standard, which
proves how the extraction from std::cin is an input operation by all rights:

<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>

Your reaction to the above was to snip all the discussion away, to tell
me that I'm a fool and that I'm misinterpreting the Standard.

Further than that, you've posted a completely new thread (this one)
where you repeatedly insulted the people who disagreed with you.

I can only ask you to keep it up: you make all of us shine!

 

[news.virginmedia.com]

I would have kept away from this thread but since you directly call me in
by name I cannot resist.

Once more you show how the interpretation you make of your very statements
is stable as a skyscraper built on the sands... I must cite again your
very first reaction after my intervention in that thread:



Once more, your very first reaction was to confirm the fact that you were
making a technical correction to Francis' words.

Eh? It's all in your head.
OK lets assume you are correct and I'm making a technical correction to
francis words.
What am I correcting?
You seem to like to start argument and twist interpretations.

After several different posts where I've tried to explain that the concept
of "input" is relative to the involved entities and to the context it is
used in - and the context into which Francis used it was perfectly fine -
I finally decided to cite the C++ standard, which proves how the
extraction from std::cin is an input operation by all rights:

Ah then you go on to focus the argument on the correct context of input.
The context of input was quite clearly user-input -> program.

Perhaps because you are non English you have a limited vocabulary. You need
to use input to mean other things and thus are extending the meaning of
input.
There are other more suitable words and phrases we can use for the process
which you are trying to apply input, such as assignment.
You are shifting the context, but you argue in such a way that you try to
make out it is me who shifts the context.

FACT: input here is used in the context of user-input-->stream.
FACT: You are shifting the context of input to mean stream->variable

<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>

Your reaction to the above was to snip all the discussion away, to tell me
that I'm a fool and that I'm misinterpreting the Standard.

Because you ARE misinterpreting these words.

If you have half a brain you will see that these words use input in the same
context I do. When they say "formatted input function" they are using input
in the context of
input data--> stream.
or
input data--> program.

There is no indication here that the authors of the standards use input in
the context of stream-> variable, as you imply.
You have posted some quote from the standards and are arguing, in a manner
that would suggest, that it supports your argument. The text you posted
actually reinforces how wrong you are.

Additionally.... just because you behave like a monkey , doesn't mean you
are one

Further than that, you've posted a completely new thread (this one) where
you repeatedly insulted the people who disagreed with you.

You insulted me first , at least i have a reason for insulting you.
You insulted a complete stranger for no reason, I only returned the insult.
Which is worse?

I can only ask you to keep it up: you make all of us shine!

If this is you shining I would not like to see you in a dull moment.

 

[Francesco S. Carta]

Eh? It's all in your head.
OK lets assume you are correct and I'm making a technical correction to
francis words.

No need to assume.

What am I correcting?

A perfectly fine and in-context post.

You seem to like to start argument and twist interpretations.



Ah then you go on to focus the argument on the correct context of input.
The context of input was quite clearly user-input -> program.

Wrong, read below.

Perhaps because you are non English you have a limited vocabulary. You
need to use input to mean other things and thus are extending the
meaning of input.
There are other more suitable words and phrases we can use for the
process which you are trying to apply input, such as assignment.
You are shifting the context, but you argue in such a way that you try
to make out it is me who shifts the context.

FACT: input here is used in the context of user-input-->stream.

Wrong, because the subject of the thread was about "while(std::cin >>
value)", that is, about the extraction process, not about the istream
getting the data.

Let's repost the OP of that thread:

> I cannot get my head around how the condition in the while statement:
>
> 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?

FACT: You are shifting the context of input to mean stream->variable

Wrong, as above, the context was, from the start, about the variable
getting the data from the stream.

<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>

Your reaction to the above was to snip all the discussion away, to
tell me that I'm a fool and that I'm misinterpreting the Standard.

Because you ARE misinterpreting these words.

If you have half a brain you will see that these words use input in the
same context I do. When they say "formatted input function" they are
using input in the context of
input data--> stream.
or
input data--> program.

There is no indication here that the authors of the standards use input
in the context of stream-> variable, as you imply.
You have posted some quote from the standards and are arguing, in a
manner that would suggest, that it supports your argument. The text you
posted actually reinforces how wrong you are.

You really really have no clue about all of this. Let's cite another
passage of the standard:

27.6.1.1 Class template basic_istream [lib.istream] p. 2

<citation>
Two groups of member function signatures share common properties: the
formatted input functions (or extractors) and the unformatted input
functions. [...]
</citation>

Once more, to the eyes of the Standard, an extractor IS an input
function. Period.

Additionally.... just because you behave like a monkey , doesn't mean
you are one

You insulted me first , at least i have a reason for insulting you.
You insulted a complete stranger for no reason, I only returned the insult.
Which is worse?

Please cite the exact message where I've insulted you.

If this is you shining I would not like to see you in a dull moment.

I still haven't seen anyone really agreeing with you so far... that
should mean that you're the only bright person posting in these very
threads and that all the others are dull... does it?

 

[news.virginmedia.com]

No need to assume.


A perfectly fine and in-context post.

Ok this seems to clarify what I originally explained and you refuse to
answer in a satisfactory manner.
So I will repeat the question with different wording.

What technical aspect of FG's post am I disputing?

Wrong, read below.


Wrong, because the subject of the thread was about "while(std::cin >>
value)", that is, about the extraction process, not about the istream
getting the data.

Are you suggesting that (cin>>value) simply extracts data from the stream
and that it does not in fact also get input from the user?
This seems to be your interpretation , which would be completely incorrect.

Let's repost the OP of that thread:

It's quite clear you refuse to acknowledge input occurs at a lower level and
are shifting the context of input, given the process as a whole.

Wrong, as above, the context was, from the start, about the variable
getting the data from the stream.

EH?
I said stream->variable, and you say no it's "the variable getting the data
from the stream."
It's exactly the same thing yet you disagree, this is total nonsense.

The problem you are twisting many things out of context and writing in a
manner that is not true of the words.

<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>

Your reaction to the above was to snip all the discussion away, to
tell me that I'm a fool and that I'm misinterpreting the Standard.

Because you ARE misinterpreting these words.

If you have half a brain you will see that these words use input in the
same context I do. When they say "formatted input function" they are
using input in the context of
input data--> stream.
or
input data--> program.

There is no indication here that the authors of the standards use input
in the context of stream-> variable, as you imply.
You have posted some quote from the standards and are arguing, in a
manner that would suggest, that it supports your argument. The text you
posted actually reinforces how wrong you are.

You really really have no clue about all of this. Let's cite another
passage of the standard:

You're be aswell citing a passage from the old testament , it aint gonna
help you if you are fundamentally wrong.

27.6.1.1 Class template basic_istream [lib.istream] p. 2

<citation>
Two groups of member function signatures share common properties: the
formatted input functions (or extractors) and the unformatted input
functions. [...]
</citation>

Are you using this to enforce your argument that the original context of
input is stream->object?
I can only deduce from this that you are indeed trying to shift the context
of input but you don't make it clear exactly what your argument is.
If this is your argument please see my comment above re 'the process as a
whole'.

Once more, to the eyes of the Standard, an extractor IS an input function.
Period.

Nobody said it wasn't. Period

Please cite the exact message where I've insulted you.

I find your general disdaining manner quite insulting.

I still haven't seen anyone really agreeing with you so far... that should
mean that you're the only bright person posting in these very threads and
that all the others are dull... does it?

You seem lost without your gang.

 

[Francesco S. Carta]

Ok this seems to clarify what I originally explained and you refuse to
answer in a satisfactory manner.
So I will repeat the question with different wording.

What technical aspect of FG's post am I disputing?

Francis wrote: "If the input operation fails for any reason then the
expression will evaluate as false." and added: "So the code can be read
as 'as long as input succeeds...". It's evident that he was speaking
about the success of the input process in general and of the last step
(the extraction) in particular.

You replied to those words with "Not Quite true according to this" and
you posted the link to a FAQ.

Saying that something is "not quite true" implies that there is
something false or wrong with that, but even assuming that you didn't
meant to interpret it in this way (you said that it was a "tongue in
cheek" statement), you added "Input can succeed but that expression
evaluate to false", which is a technical correction of Francis' words.

Now I challenge you to post a program that demonstrates successful input
/without attempting to extract the data from the stream/, just for fun.
The program must be fully conforming and must not present any
portability issue.

You know, the Standard doesn't really care how the data comes into the
stream (which would be your concept of "input", if I understand it
correctly), that's an implementation detail for the Standard, completely
out of the scope of the Standard itself.

I challenge you to post a citation of the Standard that supports /your/
concept of "input". A citation from the draft of the upcoming Standard
will be fine (that document is freely accessible), but of course, the
part you'll be citing should also be part of the /current/ Standard in
order to be valid in this discussion.

Let's try to make this clear, once more: I agree with you that the
process of std::cin getting filled with data from some external source
is /an/ input process, but it's not /the/ input process. It's just one
step of a bigger process.

The OP was interested into the /last/ step of this process, that is, the
input from std::cin to an object: Francis' post was about this and
nothing more.

Are you suggesting that (cin>>value) simply extracts data from the
stream and that it does not in fact also get input from the user?
This seems to be your interpretation , which would be completely incorrect.

Your characterization of my eventual interpretation is faulty: I can
invoke a program redirecting the content of a file to the standard input
of that program, hence attempting to extract data from std::cin will
/not/ prompt for the user input.

The process of successfully extracting the data from std::cin proves
that all the input process (including std::cin getting the data,
whatever the source) have been successful.

The problem is that you're excluding the last step of the process (the
extraction) from the whole input process. Besides, once more, the OP was
interested exactly in this last step and all the replies (except yours)
were focused about it.

It's quite clear you refuse to acknowledge input occurs at a lower level
and are shifting the context of input, given the process as a whole.


EH?
I said stream->variable, and you say no it's "the variable getting the
data from the stream."

No, you said I was shifting the context. Your sentence as a whole is
wrong, this is what I was arguing about: I was not shifting the context,
the context was already about the variable getting the data.

It's exactly the same thing yet you disagree, this is total nonsense.

The problem you are twisting many things out of context and writing in a
manner that is not true of the words.

I'm not, of course. You just misinterpreted my words.

<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>

Your reaction to the above was to snip all the discussion away, to
tell me that I'm a fool and that I'm misinterpreting the Standard.

Because you ARE misinterpreting these words.

If you have half a brain you will see that these words use input in the
same context I do. When they say "formatted input function" they are
using input in the context of
input data--> stream.
or
input data--> program.

There is no indication here that the authors of the standards use input
in the context of stream-> variable, as you imply.
You have posted some quote from the standards and are arguing, in a
manner that would suggest, that it supports your argument. The text you
posted actually reinforces how wrong you are.

You really really have no clue about all of this. Let's cite another
passage of the standard:

You're be aswell citing a passage from the old testament , it aint gonna
help you if you are fundamentally wrong.

Here lies a very important point.

These groups are about the C and the C++ languages. The Standards of
these two languages determine what is "right" and what is "wrong", when
speaking about these languages.

If you don't accept this, there is really no point in discussing with you.

27.6.1.1 Class template basic_istream [lib.istream] p. 2

<citation>
Two groups of member function signatures share common properties: the
formatted input functions (or extractors) and the unformatted input
functions. [...]
</citation>

Are you using this to enforce your argument that the original context of
input is stream->object?

Exactly, by using the above and by using the exact words of the OP. The
Standard defines the extraction as an input operation, and the OP was
concerned exactly about the extraction.

I can only deduce from this that you are indeed trying to shift the
context of input but you don't make it clear exactly what your argument is.
If this is your argument please see my comment above re 'the process as
a whole'.

Same for me, please read again all of the above. Besides, if you don't
accept the Standard this is really going to be better dropped off.

Nobody said it wasn't. Period

Well, I must cite your words again:

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.

So, weren't you saying that the extraction cannot be intended as "input"?

You questioned this more than once. Do you need more verbatim quotes
from your posts about this? I have a lot handy.

I find your general disdaining manner quite insulting.

You're failing to prove that I've insulted you, that demonstrates that
you have insulted me without any reasonable motivation.

You seem lost without your gang.

You missed the point, but you're somewhat right, I don't need any
external support, the Standard and the rules of the English language are
more than enough.

 

[news.virginmedia.com]

Francis wrote: "If the input operation fails for any reason then the
expression will evaluate as false." and added: "So the code can be read as
'as long as input succeeds...". It's evident that he was speaking about
the success of the input process in general and of the last step (the
extraction) in particular.

You say "It's evident that he was speaking about the success of the input
process in general" but then you contradict yourself by adding
"and of the last step (the extraction) in particular".
What is he speaking about, the process as a whole or simply the extraction
part?

You replied to those words with "Not Quite true according to this" and you
posted the link to a FAQ.

Saying that something is "not quite true" implies that there is something
false or wrong with that, but even assuming that you didn't meant to
interpret it in this way (you said that it was a "tongue in cheek"
statement), you added "Input can succeed but that expression evaluate to
false", which is a technical correction of Francis' words.

You said
"You have either misunderstood the FAQ or Francis' simple explanation,
because they both express the same correct concept."

To this I replied
"Input can succeed but that expression evaluate to false".

I said this in an attempt to clarify what is my understanding, after you had
accused me of lacking understanding.
This was a reply to your post, not to FG's post. This was not, as you say, a
technical correction of Francis' words.
Once again you twist things out of context.

Now I challenge you to post a program that demonstrates successful input
/without attempting to extract the data from the stream/, just for fun.
The program must be fully conforming and must not present any portability
issue.

You challenged me before when you said
'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)'

I have since posted the following:

#include <iostream>
using namespace std;

int main()
{
int x=0;
char c='\0';
cout << "Enter a char:";
cin>>x;
if(cin.fail()){
cout<< "cin>>x failed!"<<endl;
cin.clear(); //clear flags
c = cin.get(); //get whatever happens to be in the stream.
cout<< "The data obtained from cin is "<< c <<endl; //voila, the
data was input to the stream and processed by the program
}
}

The reply you gave was:
"This thread has been /brought/ to confusion, and any attempt to
straighten it out has been counter-balanced with further confusion."
Then you went on more about how your idea of input was stream-> object.

Now you seem to want to add the complication of not being allowed to extract
for proof of input?
The above code is sufficient to satisfy the original conditions.

You know, the Standard doesn't really care how the data comes into the
stream (which would be your concept of "input", if I understand it
correctly), that's an implementation detail for the Standard, completely
out of the scope of the Standard itself.

I challenge you to post a citation of the Standard that supports /your/
concept of "input". A citation from the draft of the upcoming Standard
will be fine (that document is freely accessible), but of course, the part
you'll be citing should also be part of the /current/ Standard in order to
be valid in this discussion.

You've already posted two.

Let's try to make this clear, once more: I agree with you that the process
of std::cin getting filled with data from some external source is /an/
input process, but it's not /the/ input process. It's just one step of a
bigger process.

Ok you clearly think that input in the context of streams is extraction from
the stream.
I'm sorry but I disagree.

The OP was interested into the /last/ step of this process, that is, the
input from std::cin to an object: Francis' post was about this and nothing
more.

How can you make this assumption. The OP did not say he was only interested
in the last step of the process.

Your characterization of my eventual interpretation is faulty: I can
invoke a program redirecting the content of a file to the standard input
of that program, hence attempting to extract data from std::cin will /not/
prompt for the user input.

The process of successfully extracting the data from std::cin proves that
all the input process (including std::cin getting the data, whatever the
source) have been successful.

The problem is that you're excluding the last step of the process (the
extraction) from the whole input process. Besides, once more, the OP was
interested exactly in this last step and all the replies (except yours)
were focused about it.

This is program input, we were discussing input in the context of streams.

No, you said I was shifting the context. Your sentence as a whole is
wrong, this is what I was arguing about: I was not shifting the context,
the context was already about the variable getting the data.


I'm not, of course. You just misinterpreted my words.

We obviously disagree on what input means with regards streams.

<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>

Your reaction to the above was to snip all the discussion away, to
tell me that I'm a fool and that I'm misinterpreting the Standard.

Because you ARE misinterpreting these words.

If you have half a brain you will see that these words use input in the
same context I do. When they say "formatted input function" they are
using input in the context of
input data--> stream.
or
input data--> program.

There is no indication here that the authors of the standards use input
in the context of stream-> variable, as you imply.
You have posted some quote from the standards and are arguing, in a
manner that would suggest, that it supports your argument. The text you
posted actually reinforces how wrong you are.

You really really have no clue about all of this. Let's cite another
passage of the standard:

You're be aswell citing a passage from the old testament , it aint gonna
help you if you are fundamentally wrong.

Here lies a very important point.

These groups are about the C and the C++ languages. The Standards of these
two languages determine what is "right" and what is "wrong", when speaking
about these languages.

If you don't accept this, there is really no point in discussing with you.

I do accept that but if you misinterpret the standards it's kinda pointless.

27.6.1.1 Class template basic_istream [lib.istream] p. 2

<citation>
Two groups of member function signatures share common properties: the
formatted input functions (or extractors) and the unformatted input
functions. [...]
</citation>

Are you using this to enforce your argument that the original context of
input is stream->object?

Exactly, by using the above and by using the exact words of the OP. The
Standard defines the extraction as an input operation, and the OP was
concerned exactly about the extraction.

I can only deduce from this that you are indeed trying to shift the
context of input but you don't make it clear exactly what your argument
is.
If this is your argument please see my comment above re 'the process as
a whole'.

Same for me, please read again all of the above. Besides, if you don't
accept the Standard this is really going to be better dropped off.

Are you trying to say that the standards state that input to a stream can
only be considered successful if extraction also succeeds?
You appear to be either misinterpreting something or trying to mangle words
from the standards to support your argument.

Well, I must cite your words again:

Another quote out of context

You said
'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:perator>>() '

In the context you were excluding input to the stream and I was disagreeing
with your interpretation.
I was referring the term "function of the >>" as you had interpreted it in
the previous paragraph.

So, weren't you saying that the extraction cannot be intended as "input"?

You questioned this more than once. Do you need more verbatim quotes from
your posts about this? I have a lot handy.

extraction is not the same as input, you are getting confused.

You're failing to prove that I've insulted you, that demonstrates that you
have insulted me without any reasonable motivation.

You just insulted me again by misquoting my text in an attempt to downgrade
me.

You missed the point, but you're somewhat right, I don't need any external
support, the Standard and the rules of the English language are more than
enough.

You don't seem to have a point other than to create an argument.

 

[Francesco S. Carta]

You don't seem to have a point other than to create an argument.

All right, so let's check if we really have an argument and let's do it
step by step.

I kindly ask you to reply to the following question with a "yes" or a
"no". You might eventually add any comment, as you wish (of course) and
I'll eagerly reply to any question of yours in the same manner.

You seem a very intelligent person to me, I hope you'll agree that this
is a good way to clarify any misunderstanding.

Do you object to the fact of considering the "std::cin >> object"
operation as an "input operation"?

 

[news.virginmedia.com]

All right, so let's check if we really have an argument and let's do it
step by step.

I kindly ask you to reply to the following question with a "yes" or a
"no". You might eventually add any comment, as you wish (of course) and
I'll eagerly reply to any question of yours in the same manner.

You seem a very intelligent person to me, I hope you'll agree that this is
a good way to clarify any misunderstanding.

Do you object to the fact of considering the "std::cin >> object"
operation as an "input operation"?

I see who have snipped almost everything from the previous post.
From this can we take it that you accept all the previous as correct or are
you simply avoiding these issues?