input to cin

[news.virginmedia.com]

The quote you posted from me does not contradict my words. I accept that
interpretation as being correct along with many other interpretations,
what I don't accept is your assertion about it being "what is generally
meant by input", because your assertion means that some not better
specified "majority" would on that interpretation of the word "input" as
being the "obvious one", and you cannot prove it.

You said before :
"OK, that's the meaning utilized in general when speaking about "input"
and "program", I accept it."

You don't seem to have a clue what you think about it. Make up your mind!

I hope you are able to tell the difference between a page on the Internet
and the opinion of a programmer, I also hope you're able to understand
that in order to determine the appropriate value of "50% + 1 of all the
programmers" (in order to determine the /majority/ you spoke about) you
need to know how many programmers are there in total... have you even the
slightest education about statistics?

And who wrote these technical texts on computer programming? Obvious nothing
to do with programmers, that would be too simple for you.

I feel like snipping from here on down , because it seems to be
nothing
more than a massive misinterpretation of the standards.

I'd like to see your interpretation of the same. In particular, I'd
like to see if you happen to find any reference of the process that
brings the data /to/ a program, there in the standard.

I take it you mean "references within the C++ standards" , if so I
would
say that is not within the scope of the C++ standards.

That's enough for the sake of the point I'm about to make.

I retract any non-obvious implication of your words I could have made
in the text I'm snipping out right now, let's stick just to the
opinions you have explicitly expressed.

If I happen to have missed to reply to any question of yours that you
consider important, feel free to state such questions again or to
recover the original quotes, I'll eagerly reply to them.

From your very last line above, it seems that you accept that the
meaning you have assigned to the word "input" is not covered by the
C++ standard.

Here for example is one of the standards' definitions:
1.3.2 - diagnostic message [defns.diagnostic]
a message belonging to an implementation-defined subset of the
implementation's output messages.

[please separate your citations from your text]

This definition explains how the term 'diagnostic message' is used
within the standards.

Yes, it does. Besides, please notice that it is "the standard" (singular)
as a short form for the name of a specific document about the C++
language, a document called "International Standard", which exists in
different releases and editions, where only one of these is the currently
normative one.

Was yours a typo or you mean something different when you write "the
standards" (plural)?

This does mean it would be incorrect to use this
term outside the standards in a different context.

No, it doesn't. It just means that /that/ is its meaning within the scope
of the C++ standard. The C++ standard does not care about the things
outside of its scope.

Actually I made a typo here I meant to say :
This doesn't mean it would be incorrect to use this term outside the
standards in a different context.
So you agree with me

And please note your typos, but I'm not as pedantic as you to point out
every typo in someone's post but since your doing it.

Not fully. The term is not directly defined but it is explicitly used in a
well defined case. The standard speaks about "extractors" as a synonym for
"formatted input functions", I feel it compelling to post the citation
again:

27 Input/output library 27.6.1.1 Class template basic_istream
p.2
<citation>
Two groups of member function signatures share common properties: the
formatted input functions (or extractors) and the unformatted input
functions. Both groups of input functions are described as if they obtain
(or extract) input characters by calling rdbuf()->sbumpc() or
rdbuf()->sgetc(). They may use other public members of istream.
</citation>

The standard shows a very specific usage of the word "input" in this case.

This is talking about function input. Do you not understand the difference
between function input and stream input?

It might be correct, it depends on the context it is applied to. Since it
would be outside of its scope, it simply would have no normative value.
?

The standard explicitly uses the word "input" associating it to the action
of extracting data from an istream.

Perhaps it uses input in the context of input to a function.
If it does use the the term input in the context of input from a stream,
which seems a bit confusing, then this reinforces my argument that the
stream has successfully received input.

Are you suggesting the correct use of input is as follows:
After the stream received input <em>the input was extracted from the
stream</em>

The standard never uses the word "input" associating it to the action of
bringing data into an istream - but I might have overlooked it, so it
would be nice to have "chapter and verse" pointed out, in case I'm wrong.

Try searching the standards for the term input sequence and you'll find
hundreds

It is /obvious/ that the data must come into the stream before getting
extracted, so this is /implied/ by the standard. The standard only decides
not to speak about something which happens to be an implementation
detail - the standard decides to speak about /other/ implementation
details where it is considered important.

You have agreed that it is perfectly acceptable to use a term the standards
doesn't define, or a term it does define, outside the standards in a
different context to which it is used within the standards?
Yet you contradict this by implying it's incorrect because , in your words,
the standards decides not to speak about it.

The C++ community is one thing, this group in particular is another, and
we might have different views about what should be topical here or not.
But I wont argue about it any more, it is not an important point. I don't
care about what is or isn't topical here, in this very moment.


Absolutely not. I'm asking you if you're able to understand that the C++
FAQ is about the C++ language as defined by the C++ standard.

It's not about us, about our discussions or about this group, it's just a
question about the FAQ.


I'm not suggesting anything. I'm just asking you if you're able to
understand that when he spoke about "input operation" he clearly meant to
refer to the process of extracting data from that stream, according to the
standard that defines "extractors" as a synonym for "formatted input
functions".

The question is about whether you recognize that he meant to use the word
"input" as it is used by the standard in that very well defined case.

I said it is possible to get successful input when the condition
(cin>>object was false), and this is what you raised an argument over.
Why are you trying to go back over what Francis wrote? I've already been
through all that with you.


P.S:
Please pay attention this quote from the random page
"The main purpose of the standard iostreams is to serve as a tool for
input and output of texts. Generally, input and output are the
transfer of data between a program and any kind of external source."

http://h30097.www3.hp.com/cplus/iostream.pdf

But apparently you think this wasn't written by a programmer.

 

[Francesco S. Carta]

std::cout << "Hello, World!" << std::endl;

Which would be the same as:

std::cout.operator<<("Hello, World!").operator<<(std::endl);

Heck, scratch that one, doesn't resolve correctly... this is better:

cout << someint << endl;

cout.operator<<(someint).operator<<(endl);

Alf, couldn't you have had a look before sending us back from aula magna
to the classroom? ;-)

 

[Francesco S. Carta]

You said before :
"OK, that's the meaning utilized in general when speaking about "input"
and "program", I accept it."

You don't seem to have a clue what you think about it. Make up your mind!

I don't recall and I don't find it urgent to look it up in order to
check what I accepted, please post it again within sufficient context -
if you (will) really find it necessary.

Please post your reply to my post in the other branch of this thread
(the recent intervention of Francis Glassborow), it's way more important
to clear the core of our misunderstandings.

 

[news.virginmedia.com]

Yes, you're for real. I'll show you something.

This is a C "input function":

int getchar(void);

When /physically/ regarded as a /function/ this one in particular gets no
"input", because it takes no parameters, it just performs an "output": it
returns an int.

Hundreds of functions take no input, what is your point?

Still, that function performs /logically/ as an input function because it
permits us to get a char from stdin, which is the standard input "channel"
used to transmit the data from the "outside" of the program to its
"inside" (its objects or variables).

You stated previously that it didn't get input.
Make up your mind , does it get input or doesn't it?
Or it is a case of it can sometimes it gets input and sometimes not? If so
why not simply say this and .. so what.

Do you realize that when you speak about "input to function" you are
speaking about the fact of passing parameters to it, are you? no you don't say.

Here below are several "input functions" in C++. These are, obviously,
methods of the std::cin object.

One of these functions gets no input (no arguments) and outputs (returns)
an int just like the above C function:

int istream::get();

All of the following functions output (return) an std::istream (input
stream) reference - this is what permits us to chain them (and
collaterally, to use them in boolean tests):

istream& istream::get( char& ch );
istream& istream::get( char* buffer, streamsize num );
istream& istream::get( char* buffer, streamsize num, char delim );
istream& istream::get( streambuf& buffer );
istream& istream::get( streambuf& buffer, char delim );

Also, each of the above takes different inputs (different parameters).

Extractors are operators, that's correct, but they also are functions.

When you create extractors for your "stream" classes you declare them as
functions and you can call them directly as functions - from there on you
can also use extractor operators on your classes, of course.

This instruction:

std::cin >> variable;

Is equivalent to this one:

std::cin.operator>>(variable);

When discussing streams, the input /to the stream/ is called OUTPUT.

That's why we have an std:stream" (an output stream) called std::cout.

And we normally "output" using inserters:

std::cout << "Hello, World!" << std::endl;

Which would be the same as:

std::cout.operator<<("Hello, World!").operator<<(std::endl);

Those are all well formed, working lines (when compiled in an appropriate
context).

Yeah so you imply you are capable of deriving a stream class and overloading
operators, and does this make you super?

Please let me tell that you are (you were?) not aware of what you are (you
were?) speaking about. I hope that the above clarified your ideas about
the subject, at least a bit.

This looks like bad grammar, don't have a clue what it's supposed to mean.

Here's another good link for you:
http://cplus.about.com/od/learning1/ss/clessontwo.htm

Please pay attention to the text:
<quote>
The iostream class provides access to the objects and methods you need for
both output and input. Think of i/o in terms of streams of bytes- either
going from your application to a file, the screen or a printer - that's
output, or from the keyboard - that's input.
</quote>

 

[news.virginmedia.com]

I don't recall and I don't find it urgent to look it up in order to check
what I accepted, please post it again within sufficient context - if you
(will) really find it necessary.

You don't need to look it up , that is the quote.

Please post your reply to my post in the other branch of this thread (the
recent intervention of Francis Glassborow), it's way more important to
clear the core of our misunderstandings.

Already did , please pay attention to the link at the bottom you may learn
something.

 

[news.virginmedia.com]

* Francesco S. Carta, on 19.09.2010 00:58:

news.virginmedia.com <[email protected]>, on 18/09/2010 23:09:01,
wrote:

Hey, can you guys please stop cross-posting to [comp.lang.c++]?

Ehehehe, I think we are almost done ;-)

phsyco killer verse 2

 

[James Kanze]

Thank you very much for your words Christian.

You know what? I'm still not convinced about the fact that he
is a genuine troll. There is a reason for which I've kept this
up that far (even if, of course, it's a personal motivation of
mine which is far from being evident, I suppose) I'll make
another try because I feel we are getting to the point,
finally, after about one hundred posts.

The word troll gets bandied around a lot; he's not a troll in
the classical sense (since a troll doesn't participate after the
first triggering post), but the effect is the same.

With regards to the initial premise: if I "input an int", and I
don't get an int, then the input has failed. There's no other
reasonable way of looking at it. Enough said.

 

[Francesco S. Carta]

* Francesco S. Carta, on 19.09.2010 00:58:
news.virginmedia.com <[email protected]>, on 18/09/2010 23:09:01,
wrote:

Hey, can you guys please stop cross-posting to [comp.lang.c++]?

Ehehehe, I think we are almost done ;-)

phsyco killer verse 2

I'll take that as a compliment

 

[Francesco S. Carta]

Hundreds of functions take no input, what is your point?

The point is to show that there are functions that don't get any input
and that, strangely, give us some input. Furthermore they happen to be
called "input functions"... that's /really/ strange, isn't it?

You stated previously that it didn't get input.
Yep.

Make up your mind , does it get input or doesn't it?

It doesn't.

Please notice that "it gets something" and "it gets me something" are
two very different concepts.

Or it is a case of it can sometimes it gets input and sometimes not? If
so why not simply say this and .. so what.

No "intermittent" case there. The function does not get any input, but
still, when I call it, it gets me the input.

You show that you have very hard time distinguishing the meaning of the
word "input" depending on the context it is used, even in very simple
sentences.

Unfortunately, that word doesn't suffer of solitude, and I feel I'm
being overly evil with this "words game".

no you don't say.

That response has no meaning.

Can you tell me the difference between "input to function" and "input
function"?

Yeah so you imply you are capable of deriving a stream class and
overloading operators, and does this make you super?

No, I did not mean to imply that - besides, yes, I am capable of doing
such basic stuff and unfortunately that does not make me "super" at all.

This looks like bad grammar, don't have a clue what it's supposed to mean.

That does not surprise me at all, at this point.

<translation>
Please let me tell that you are not aware of what you are speaking
about. Or should I say: "Please let me tell that you were not aware of
what you were speaking about."?
</translation>

Unfortunately I have to keep the present tense in that sentence.

For your information, it wasn't that /hard/ to understand.

Here's another good link for you:
http://cplus.about.com/od/learning1/ss/clessontwo.htm

Please pay attention to the text:
<quote>
The iostream class provides access to the objects and methods you need
for both output and input. Think of i/o in terms of streams of bytes-
either going from your application to a file, the screen or a printer -
that's output, or from the keyboard - that's input.
</quote>

I've paid attention: it is a reasonable and simple outline of the
subject. Though, it is really far from being technically exhaustive (it
is not meant to be so, of course).

I'm not so sure I'll reply to your other post down there in the other
branch... uhmmmm, OK, I will make these last attempts.

 

[Francesco S. Carta]

You don't need to look it up , that is the quote.

All right, I'll do the dirty work of recovering the context, but I'll do
it in the post where you have just pointed it out, so that I can take
the chance to answer to all of the other points.

Already did , please pay attention to the link at the bottom you may
learn something.

Indeed I may, I have learnt a lot of things so far.

 

[Francesco S. Carta]

You said before :
"OK, that's the meaning utilized in general when speaking about "input"
and "program", I accept it."

You don't seem to have a clue what you think about it. Make up your mind!

Ah, yes, that sentence of mine was and still is in agreement with the
rest of my writings. I posted that in reply to [the paragraph that
contained] this link:

http://en.wikipedia.org/wiki/Standard_streams

Take the chance to open that page once more and look at that nifty
picture where the word "program" is enclosed by an oval. That oval is
there to mean the program as a whole, and the picture depicts the
interaction of the program (as a whole) with the environment.

But, you know, we were speaking about extractors, we were /inside/ of
that oval.

I know that the internals of a C++ program could appear as an
unintelligible machinery made up of different but almost
indistinguishable funnels, conveyor belts, gears, screws, levers, shafts
and springs, but with a bit of effort you'll be able to discern between
"an input function" and "input to a function".

And who wrote these technical texts on computer programming? Obvious
nothing to do with programmers, that would be too simple for you.

I find it is very easy for /you/ to post a web search and pretend it
proves that "this interpretation is generally what is meant by input by
99.999999% of programmers across the globe" which is the original
sentence that brought you to post that web search link.

Please don't replace that figure with "majority" once more, that does
not remove an ounce from the absurdity of your claim.

I feel like snipping from here on down , because it seems to be
nothing
more than a massive misinterpretation of the standards.

I'd like to see your interpretation of the same. In particular, I'd
like to see if you happen to find any reference of the process that
brings the data /to/ a program, there in the standard.

I take it you mean "references within the C++ standards" , if so I
would
say that is not within the scope of the C++ standards.

That's enough for the sake of the point I'm about to make.

I retract any non-obvious implication of your words I could have made
in the text I'm snipping out right now, let's stick just to the
opinions you have explicitly expressed.

If I happen to have missed to reply to any question of yours that you
consider important, feel free to state such questions again or to
recover the original quotes, I'll eagerly reply to them.

From your very last line above, it seems that you accept that the
meaning you have assigned to the word "input" is not covered by the
C++ standard.

Here for example is one of the standards' definitions:
1.3.2 - diagnostic message [defns.diagnostic]
a message belonging to an implementation-defined subset of the
implementation's output messages.

[please separate your citations from your text]

This definition explains how the term 'diagnostic message' is used
within the standards.

Yes, it does. Besides, please notice that it is "the standard"
(singular) as a short form for the name of a specific document about
the C++ language, a document called "International Standard", which
exists in different releases and editions, where only one of these is
the currently normative one.

Was yours a typo or you mean something different when you write "the
standards" (plural)?

This does mean it would be incorrect to use this
term outside the standards in a different context.

No, it doesn't. It just means that /that/ is its meaning within the
scope of the C++ standard. The C++ standard does not care about the
things outside of its scope.

Actually I made a typo here I meant to say :
This doesn't mean it would be incorrect to use this term outside the
standards in a different context.
So you agree with me

Indeed. I've agreed to several assertions of yours. I don't have any
problem making such "concessions" to you.

And please note your typos, but I'm not as pedantic as you to point out
every typo in someone's post but since your doing it.

I have not pointed out a typo in your post, I have /asked/ you whether
that was a typo or not. From the above it seems that you're saying "the
standards" (plural) was a typo, strange... a typo happens once in a
while, you /systematically/ spell it as plural.

This is talking about function input. Do you not understand the
difference between function input and stream input?

Heck, I'm beginning to think I don't!

Please, please, tell me, what is the difference between all of the
following?

"input function"
"function input"
"stream input"
"input stream"
"input to function"
"input to stream"
"input from function"
"input from stream"

Hint: I /am/ able to discern them and to assign appropriate meanings to
all of the above, the problem is whether /you/ are able to do the same.

?

What is the word that you happen to be missing in that sentence,
"normative" perhaps?

Perhaps it uses input in the context of input to a function.

Absolutely not, of course, because the concept of "input to a function"
is expressed as "passing parameters to a function", the standard does
not use words so sloppily as you do.

If it does use the the term input in the context of input from a stream,
which seems a bit confusing, then this reinforces my argument that the
stream has successfully received input.

Are you suggesting the correct use of input is as follows:
After the stream received input <em>the input was extracted from the
stream</em>

"/the/ correct use of input" does not exist. There are several different
correct uses for it, and telling that the extraction process is an input
process is perfectly fine under both the rules of the standard C++
language and the rules of the English language.

Try searching the standards for the term input sequence and you'll find
hundreds

It's /you/ who has to back up /your/ assertions. Chapter and verse, please.

You have agreed that it is perfectly acceptable to use a term the
standards doesn't define, or a term it does define, outside the
standards in a different context to which it is used within the standards?
Yes.

Yet you contradict this by implying it's incorrect because , in your
words, the standards decides not to speak about it.

No contradiction. You incorrectly used the word "input" by using it in a
context (the extraction of some data /from/ the input stream) with an
out-of-context meaning (the insertion of external-to-the-program data
/in/ the input stream).

I said it is possible to get successful input when the condition
(cin>>object was false), and this is what you raised an argument over.

The above is way different from what you initially claimed.

It was the approximative exposition of your trivial and obvious
out-of-context observation that raised the argument.

Why are you trying to go back over what Francis wrote? I've already been
through all that with you.

Yes, we have been through that, your general understanding of the matter
has been measured and found extremely lacking.

P.S:
Please pay attention this quote from the random page
"The main purpose of the standard iostreams is to serve as a tool for
input and output of texts. Generally, input and output are the
transfer of data between a program and any kind of external source."

Indeed. Once more, that "general meaning" was completely out of context
when stuffed into a discussion about extracting data from the input stream.

But apparently you think this wasn't written by a programmer.

It has been written by a programmer, I suppose.

What I question is the fact of considering /you/ as a programmer, due to
your extremely lacking understanding of the whole matter.

Your turn.

 

[news.virginmedia.com]

Give up, the bloke's an arse.

Totally
But I'm going prove the idiot is nothing more that a twisted little worm,
Thx.

 

[Francesco S. Carta]

Totally
But I'm going prove the idiot is nothing more that a twisted little worm,
Thx.

Have you considered the eventuality of Ian speaking /to/ me and not
/about/ me?

Anyway, I'm waiting for your replies, I'm really curious to see them.

[to anybody else reading: don't panic, I'll tell you how this is going
to finish: tomorrow I'll start working and I'll have no more time to
"waste" (although I don't feel I wasted my time, so far), so I'll
abandon these very threads and Paul will declare his definitive victory,
for the good rest of any reasonable logic and of the English language]

 

[news.virginmedia.com]

The point is to show that there are functions that don't get any input and
that, strangely, give us some input. Furthermore they happen to be called
"input functions"... that's /really/ strange, isn't it?


It doesn't.

Please notice that "it gets something" and "it gets me something" are two
very different concepts.


No "intermittent" case there. The function does not get any input, but
still, when I call it, it gets me the input.

hmm you seem a tad confused.

You show that you have very hard time distinguishing the meaning of the
word "input" depending on the context it is used, even in very simple
sentences.

I think it's more a case of you cannot express input clearly.

Unfortunately, that word doesn't suffer of solitude, and I feel I'm being
overly evil with this "words game".


That response has no meaning.

FYO It means you are stating the obvious.

Can you tell me the difference between "input to function" and "input
function"?
Yes

No, I did not mean to imply that - besides, yes, I am capable of doing
such basic stuff and unfortunately that does not make me "super" at all.

you say that creating a stream class is basic , hmm interesting.

That does not surprise me at all, at this point.

<translation>
Please let me tell that you are not aware of what you are speaking about.
Or should I say: "Please let me tell that you were not aware of what you
were speaking about."?
</translation>

Unfortunately I have to keep the present tense in that sentence.

For your information, it wasn't that /hard/ to understand.

Why didn't you simply say... you don't know what your speaking about ?

I've paid attention: it is a reasonable and simple outline of the subject.
Though, it is really far from being technically exhaustive (it is not
meant to be so, of course).

I'm not so sure I'll reply to your other post down there in the other
branch... uhmmmm, OK, I will make these last attempts.

--

I think we should abort this branch of the thread as the other branch
addresses all these issues.

 

[news.virginmedia.com]

You said before :
"OK, that's the meaning utilized in general when speaking about "input"
and "program", I accept it."

You don't seem to have a clue what you think about it. Make up your mind!

Ah, yes, that sentence of mine was and still is in agreement with the rest
of my writings. I posted that in reply to [the paragraph that contained]
this link:

http://en.wikipedia.org/wiki/Standard_streams

Take the chance to open that page once more and look at that nifty picture
where the word "program" is enclosed by an oval. That oval is there to
mean the program as a whole, and the picture depicts the interaction of
the program (as a whole) with the environment.

But, you know, we were speaking about extractors, we were /inside/ of that
oval.

I know that the internals of a C++ program could appear as an
unintelligible machinery made up of different but almost indistinguishable
funnels, conveyor belts, gears, screws, levers, shafts and springs, but
with a bit of effort you'll be able to discern between "an input function"
and "input to a function".

Funny how you imply that I don't understand these two concepts when It was
me who initially pointed it out.

I find it is very easy for /you/ to post a web search and pretend it
proves that "this interpretation is generally what is meant by input by
99.999999% of programmers across the globe" which is the original sentence
that brought you to post that web search link.

Please don't replace that figure with "majority" once more, that does not
remove an ounce from the absurdity of your claim.

ok in your own words
"OK, that's the meaning utilized in general when speaking about "input" and
"program", I accept it."

The statistics of the evidence is irrelevant if you have already agreed to
this so there's no point in arguing about it.

I feel like snipping from here on down , because it seems to be
nothing
more than a massive misinterpretation of the standards.

I'd like to see your interpretation of the same. In particular, I'd
like to see if you happen to find any reference of the process that
brings the data /to/ a program, there in the standard.

I take it you mean "references within the C++ standards" , if so I
would
say that is not within the scope of the C++ standards.

That's enough for the sake of the point I'm about to make.

I retract any non-obvious implication of your words I could have made
in the text I'm snipping out right now, let's stick just to the
opinions you have explicitly expressed.

If I happen to have missed to reply to any question of yours that you
consider important, feel free to state such questions again or to
recover the original quotes, I'll eagerly reply to them.

From your very last line above, it seems that you accept that the
meaning you have assigned to the word "input" is not covered by the
C++ standard.

Here for example is one of the standards' definitions:
1.3.2 - diagnostic message [defns.diagnostic]
a message belonging to an implementation-defined subset of the
implementation's output messages.

[please separate your citations from your text]

This definition explains how the term 'diagnostic message' is used
within the standards.

Yes, it does. Besides, please notice that it is "the standard"
(singular) as a short form for the name of a specific document about
the C++ language, a document called "International Standard", which
exists in different releases and editions, where only one of these is
the currently normative one.

Was yours a typo or you mean something different when you write "the
standards" (plural)?

This does mean it would be incorrect to use this
term outside the standards in a different context.

No, it doesn't. It just means that /that/ is its meaning within the
scope of the C++ standard. The C++ standard does not care about the
things outside of its scope.

Actually I made a typo here I meant to say :
This doesn't mean it would be incorrect to use this term outside the
standards in a different context.
So you agree with me

Indeed. I've agreed to several assertions of yours. I don't have any
problem making such "concessions" to you.

And please note your typos, but I'm not as pedantic as you to point out
every typo in someone's post but since your doing it.

I have not pointed out a typo in your post, I have /asked/ you whether
that was a typo or not. From the above it seems that you're saying "the
standards" (plural) was a typo, strange... a typo happens once in a while,
you /systematically/ spell it as plural.

This is talking about function input. Do you not understand the
difference between function input and stream input?

Heck, I'm beginning to think I don't!

Please, please, tell me, what is the difference between all of the
following?

"input function"
"function input"
"stream input"
"input stream"
"input to function"
"input to stream"
"input from function"
"input from stream"

Hint: I /am/ able to discern them and to assign appropriate meanings to
all of the above, the problem is whether /you/ are able to do the same.

So what is the difference between 'function input' and 'input to function'?

What is the word that you happen to be missing in that sentence,
"normative" perhaps?

No I'm confused how you can state that the term input can have no value,
whether it be normative or not .

Absolutely not, of course, because the concept of "input to a function" is
expressed as "passing parameters to a function", the standard does not use
words so sloppily as you do.


"/the/ correct use of input" does not exist. There are several different
correct uses for it, and telling that the extraction process is an input
process is perfectly fine under both the rules of the standard C++
language and the rules of the English language.

No this is where you are completely incorrect.
Lets look at that exert from the standards again:
"Both groups of input functions are described as if they obtain (or extract)
input characters by calling rdbuf()->sbumpc() or rdbuf()->sgetc()."
The standards clearly do not define the extraction process as input process
Input does not mean the same as extraction , that's simply wrong whether it
be in the context of the English language or C++ language.

You're interpretation of the standards is very err sloppy, no that's wrong
your interpretation is simply incorrect.

It's /you/ who has to back up /your/ assertions. Chapter and verse,
please.

"27.5.1 - Stream buffer requirements [lib.streambuf.reqts]
-1- Stream buffers can impose various constraints on the sequences they
control. Some constraints are:
The controlled input sequence can be not readable."

Enough?

No contradiction. You incorrectly used the word "input" by using it in a
context (the extraction of some data /from/ the input stream) with an
out-of-context meaning (the insertion of external-to-the-program data /in/
the input stream).

You incorrectly refer to input here as extraction of data from a stream.
If input is used in this context it must be considered a noun but you are
applying input(as a verb) to this context.
For example:
The stream received input and this input was then extracted from the stream.

To say the data was input from the stream is simply wrong.

The above is way different from what you initially claimed.

It was the approximative exposition of your trivial and obvious
out-of-context observation that raised the argument.

Here is the conversation from the original 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.
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.
</snippet>

This is where you raised the argument about what was or wasn't considered
input.

Yes, we have been through that, your general understanding of the matter
has been measured and found extremely lacking.

Another random put-down that lacks any real proof or evidence.

Indeed. Once more, that "general meaning" was completely out of context
when stuffed into a discussion about extracting data from the input
stream.

The original discussion was about the expression (cin>>x) in general.
Are you suggesting the expression cin>>x does nothing more than extract data
from a stream?

It has been written by a programmer, I suppose.

What I question is the fact of considering /you/ as a programmer, due to
your extremely lacking understanding of the whole matter.

You'll find it's you who lacks understanding

 

[news.virginmedia.com]

To say the data was input from the stream is simply wrong.

<snip>

I must clarify I use input as a verb in this statement.

 

[news.virginmedia.com]

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.

I think its quite clear that YOU miss the meaning of a successful input
operation.
I have proven FG technically incorrect on almost everything he's said, who
ever he is I don't care but obviously you think he is something special.
For whatever reason I dunno, maybe you are gay lovers. I don't have a clue
and I don't care. Good Luck

 

[Öö Tiib]

I don't have a clue and I don't care.

Thinking people communicate with each other to share information.
Information exchange goes like that input --> processing --> output.
Between people themselves, between people and computers and within
computers on all levels down to single instructions.

The whole discussion is demonstrating that something in your
processing and/or your output module is damaged so obscenities,
insults and nonsense come out. About input it is hard to tell maybe
you made successful input operation but further processing and output
failed.

 

[news.virginmedia.com]

Thinking people communicate with each other to share information.
Information exchange goes like that input --> processing --> output.
Between people themselves, between people and computers and within
computers on all levels down to single instructions.

The whole discussion is demonstrating that something in your
processing and/or your output module is damaged so obscenities,
insults and nonsense come out. About input it is hard to tell maybe
you made successful input operation but further processing and output
failed.

Output was successful on my part as I made my point clear. Your output
however seems to be somewhat obscure, is this a feeble attempt to insult me?
I've seen enough senseless idiotic replies here to make a room full of
retards look intelligent and your addition is no different.