input to cin

[Francesco S. Carta]

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?

None of the two options. We will return to every and each step at due
time, if you'll consider it necessary.

I'm just trying to clarify your last objection, that is, the fact that I
could be creating an argument where there might be none in reality.

You might think that I'm kidding or something, but I'm serious.

I'm seriously thinking that I could have been creating something out of
the void, and I'm seeking your help in order to clarify it.

So, according to your view of the word "input", would you call "input"
the action of transferring some data from std::cin to an object?

 

[news.virginmedia.com]

None of the two options. We will return to every and each step at due
time, if you'll consider it necessary.

I'm just trying to clarify your last objection, that is, the fact that I
could be creating an argument where there might be none in reality.

You might think that I'm kidding or something, but I'm serious.

I'm seriously thinking that I could have been creating something out of
the void, and I'm seeking your help in order to clarify it.

So, according to your view of the word "input", would you call "input" the
action of transferring some data from std::cin to an object?

--

I don't see how I can be any more clear about my view of input.
I will state my view once again if it makes it any clearer:

With regards to the input streams which is the current context we're
referring to, we have:
source data -> stream -> object.
In this scenario I regard the input as the step data-> stream.

The question you put forward is... would I call the next step of this
process input re:
stream -> object
This could be regarded as input to the object but if you call this input is
becomes confused with the main input process. It's much less confusing to
simply call this extraction or use some other word or phrase.

Now if you look at it from another perspective you could have:
input data -> program
I consider this interpretation to be the general interpretation of input as
explained in this general link.
http://en.wikipedia.org/wiki/Standard_streams
In fact if I do a web search on 'input stream', 99% of relevant results
refer to input in this way.

You do not seem to accept these more generally interpretations of input ,
and you keep trying to say that input is stream -> object.
Just do a simple web search and the evidence against this is overwhelming,
for this reason I feel you are simply trying to create an argument by
dismissing my views time after time.

 

[Francesco S. Carta]

I don't see how I can be any more clear about my view of input.

It is normal for our very views to be clear to ourselves, but anyone
else can find it hard to see it in the same way because they happen to
look from a different perspective.

I will state my view once again if it makes it any clearer:

Thank you very much, I feel it was necessary for me.

With regards to the input streams which is the current context we're
referring to, we have:
source data -> stream -> object.
In this scenario I regard the input as the step data-> stream.

I accept it, that's your point of view.

The question you put forward is... would I call the next step of this
process input re:
stream -> object
This could be regarded as input to the object but if you call this input
is becomes confused with the main input process. It's much less
confusing to simply call this extraction or use some other word or phrase.

OK, so, if I'm not mistaken, your reply to my question is "yes", but you
make the caveat that it makes things confused because you assign more
importance to the "main input process", which, for you, is the process
of bringing the data from the external source to std::cin.

I accept it, that's your point of view.

Now if you look at it from another perspective you could have:
input data -> program
I consider this interpretation to be the general interpretation of input
as explained in this general link.
http://en.wikipedia.org/wiki/Standard_streams
In fact if I do a web search on 'input stream', 99% of relevant results
refer to input in this way.

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

You do not seem to accept these more generally interpretations of input
, and you keep trying to say that input is stream -> object.

No, please let me correct this. I fully accept these generic
interpretations - on the contrary, I've repeatedly stated that the word
"input" can, by all rights, be assigned to the process of the program
getting the data from an external source.

Just do a simple web search and the evidence against this is
overwhelming, for this reason I feel you are simply trying to create an
argument by dismissing my views time after time.

I don't think I've dismissed your views, but if I happened to give that
impression I can assure you that it was not my purpose.

Please let me state once more that I fully accept your point of view, it
is reasonable and shared among many, many people and pages all around
the web.

Now I'd like to expose, with your permission, my point of view about the
core and birth of our disagreement.

I cannot speak about anyone else that has participated in our
discussions, so I'll speak only about myself.

As a C++ programmer, I am accustomed to interpret the questions that get
posted in these groups (specifically, the very words those questions are
composed with) under the light of the C++ Standard. I feel it compelling
because it is a good way to avoid a lot of misunderstanding and
unfruitful debates about the meaning of a word.

To make a silly example just because it happens to be a word that
already appeared: when I see the word "extractor" or "extraction" I
immediately think about operator>>() and not about dental surgery or
surgery tools, and I happen to think about operator>>() because these
groups are focused about the C++ language as it is defined by the C++
Standard.

You might have noticed that any "variant" of the C++ language (I mean
the various platform specific or implementation specific extensions or
details that happen to be used, rightfully, within a C++ program) are
considered off-topic here, and the usual reply one gets when posting
questions about such topics is to find a better group to post them.

The same happens with the word "input" when used as meaning "the process
of bringing the data from an external source to std::cin", because it
happens to be an implementation dependent detail, there is nothing
"Standard" with it.

When I first read the word "input" in that "famous" thread my mind
immediately translated it into "input from a stream to an appropriate
variable", because that's the meaning intended by the C++ Standard.

You can guess that, when /you/ used the word "input" in that "famous"
thread, that /still/ meant "input from the stream to a variable" for me.

The fact that you did not specify immediately what meaning you were
assigning to the word "input" helped to develop a lot of
misunderstanding for me because yours, to my eyes, was not /the obvious
meaning/ in the context of these very groups.

That was the cause of my accusation about you shifting the context from
the /obvious for me/ meaning (stream --> variable) to the /obvious for
you/ meaning (external source --> stream).

Now, I repeat, I cannot really speak for the others, but I think that
the /obvious for me/ meaning is also the /obvious for the group/
meaning, not because I think everybody else actually /thinks/ so but
because everybody else should keep as reference what is /obvious for the
C++ Standard/.

I hope I have clarified my point of view on the matter.

 

[Francesco S. Carta]

OK, so, if I'm not mistaken, your reply to my question is "yes", but you
make the caveat that it makes things confused because you assign more
importance to the "main input process", which, for you, is the process
of bringing the data from the external source to std::cin.

Sorry, of course that was a "no" and the caveat was actually just a
rationale.

I any case, I'm perfectly fine with that, that's your point of view and
I accept it.

Please consider this correction in your reply to my other post.

 

[news.virginmedia.com]

So that is a very long way of writing 'No' ? Correct me if I am mistaken.

However note that the C++ Standard (which in context is what we are
talking about) talks about input functions.

Is this is forum about the C++ standards? No.
So now YOU want to change the context to that of the standards?

You are also missing the big picture, that is you fail to acknowledge the
stream object.
As the >> operator is a member of the stream object I think It is
unreasonable to ignore it.

A function is evaluated and in the case of operator >> the result is a
pointer value which can, when necessary, be converted to a bool. I think it
is not unreasonable to think that an input function does input, though in
this case the input seems to be to a variable.

You , like Francesco, seem to be focusing ONLY on the extraction. You seem
to be trying to say that the main input process is extraction from the
stream to an object.

Ok lets say we are creating an input processing function, what is one of the
first things this function must to do?
Check for successful input.
Yes this function can be called an input function , or an input processing
function, but context of input here is input to the function because the
focus is the function.
If the focus is the stream the input is input to stream.

I think the Standard is written that way because the 'input functions' are
not required to get external input, it may be provided from within the
program. Yes it might have been better to have called them extraction
functions and if you feel strongly you can go to comp.std.C++ and raise a
defect report. That is where such word games belong.

When people write standards their context is different as they are defining
a language, let me explain:

Suppose we a given a project to create a C++ stream library that reads and
write to a USB device.
But the C++ standards don't define USB devices, therefore its not a valid
C++ program? Of course this is wrong, it's is because the C++ standards are
in a different context.

You seem to be misinterpreting the purpose of the C++ standards as a
definition of the contextual interpretation of software engineering terms.
The C++ Standards is simply a guide that defines the expected behavior of
the language, it certainly doesn't define software engineering terms.

 

[news.virginmedia.com]

It is normal for our very views to be clear to ourselves, but anyone else
can find it hard to see it in the same way because they happen to look
from a different perspective.


Thank you very much, I feel it was necessary for me.


I accept it, that's your point of view.


OK, so, if I'm not mistaken, your reply to my question is "yes", but you
make the caveat that it makes things confused because you assign more
importance to the "main input process", which, for you, is the process of
bringing the data from the external source to std::cin.

I accept it, that's your point of view.


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


No, please let me correct this. I fully accept these generic
interpretations - on the contrary, I've repeatedly stated that the word
"input" can, by all rights, be assigned to the process of the program
getting the data from an external source.

What do you mean by "can by all rights be"?
Do you accept the fact that this interpretation is generally what is meant
by input by 99.999999% of programmers across the globe?

Even given this massively overwhelming evidence you still attempt to deny it
as THE general interpretation by saying...
"the word
"input" can, by all rights, be ". I emphasise the CAN.



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

I don't think I've dismissed your views, but if I happened to give that
impression I can assure you that it was not my purpose.

Please let me state once more that I fully accept your point of view, it
is reasonable and shared among many, many people and pages all around the
web.

Now I'd like to expose, with your permission, my point of view about the
core and birth of our disagreement.

I cannot speak about anyone else that has participated in our discussions,
so I'll speak only about myself.

As a C++ programmer, I am accustomed to interpret the questions that get
posted in these groups (specifically, the very words those questions are
composed with) under the light of the C++ Standard.
I feel it compelling

LOL, you treat this standard like a holy man treats the bible.
I'm sorry to ruin your party but this is not a forum about the C++
standards.

because it is a good way to avoid a lot of misunderstanding and unfruitful
debates about the meaning of a word.

No the standard does not define words, perhaps C++ keywords but it
certainly does not define software engineering terms.
Considering your obviously high level of regard for the C++ standard, your
going to be pretty peed off when you realise how badly you misinterpret it.
If you ever do face up to the truth.

To make a silly example just because it happens to be a word that already
appeared: when I see the word "extractor" or "extraction" I immediately
think about operator>>() and not about dental surgery or surgery tools,
and I happen to think about operator>>() because these groups are focused
about the C++ language as it is defined by the C++ Standard.

Oh your talking about the standards again , sigh.
Hurry up and realise that you misinterpret.

You might have noticed that any "variant" of the C++ language (I mean the
various platform specific or implementation specific extensions or details
that happen to be used, rightfully, within a C++ program) are considered
off-topic here, and the usual reply one gets when posting questions about
such topics is to find a better group to post them.

You want a job on the board? LOL.

The same happens with the word "input" when used as meaning "the process
of bringing the data from an external source to std::cin", because it
happens to be an implementation dependent detail, there is nothing
"Standard" with it.

When I first read the word "input" in that "famous" thread my mind
immediately translated it into "input from a stream to an appropriate
variable", because that's the meaning intended by the C++ Standard.

You can guess that, when /you/ used the word "input" in that "famous"
thread, that /still/ meant "input from the stream to a variable" for me.

The fact that you did not specify immediately what meaning you were
assigning to the word "input" helped to develop a lot of misunderstanding
for me because yours, to my eyes, was not /the obvious meaning/ in the
context of these very groups.

That was the cause of my accusation about you shifting the context from
the /obvious for me/ meaning (stream --> variable) to the /obvious for
you/ meaning (external source --> stream).

Now, I repeat, I cannot really speak for the others, but I think that the
/obvious for me/ meaning is also the /obvious for the group/ meaning, not
because I think everybody else actually /thinks/ so but because everybody
else should keep as reference what is /obvious for the C++ Standard/.

I hope I have clarified my point of view on the matter.

--

Its quite obvious you think the context of the standards applies here, but
you are incorrect.
You cannot accept the truth ,that is the general concept of input with
regards to software engineering, more specifically streams.
Do I have to post 100 links to prove you are in the minority or are you
going to realise the truth?

 

[Francesco S. Carta]

What do you mean by "can by all rights be"?
Do you accept the fact that this interpretation is generally what is
meant by input by 99.999999% of programmers across the globe?

Nope, I cannot accept it, because it is a number pulled out of thin air.

Even given this massively overwhelming evidence you still attempt to
deny it as THE general interpretation by saying...
"the word
"input" can, by all rights, be ". I emphasise the CAN.

In the Oxford dictionary, one of the definitions of the word "input" is
"the action of putting something in". This is one of the general
/meanings/ of this word according to an authoritative source about the
English language. Further than that, we have a lot of different
/interpretations/ that are strictly tied to the context the word it is
used in.

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.

But I'll leave it.


LOL, you treat this standard like a holy man treats the bible.
I'm sorry to ruin your party but this is not a forum about the C++
standards.

This is a forum about the C++ language /as defined/ by the C++ standard.

From the "Read this first" of comp.lang.c++:

"First of all, please keep in mind that comp.lang.c++ is a group for
discussion of general issues of the C++ programming language, as defined
by the ANSI/ISO language standard"

Here the standard is normally taken for granted and not normally
questioned, there is a more fitting group for that: comp.std.c++

No the standard does not define words, perhaps C++ keywords but it
certainly does not define software engineering terms.

There are more fitting groups for "software engineering" in general.

Considering your obviously high level of regard for the C++ standard,
your going to be pretty peed off when you realise how badly you
misinterpret it. If you ever do face up to the truth.

Once more, I'd like to see your interpretation of the same about this
subject. In particular, once more, 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.

Oh your talking about the standards again , sigh.
Hurry up and realise that you misinterpret.

You want a job on the board? LOL.

I don't, but nothing would forbid me to if I wanted.

Its quite obvious you think the context of the standards applies here,
but you are incorrect.

Read the "read me first" of this group, if you never did.

You cannot accept the truth ,that is the general concept of input with
regards to software engineering, more specifically streams.

This group is /not/ about software engineering, it is about the C++
language.

Do I have to post 100 links to prove you are in the minority or are you
going to realise the truth?

What should I say, now, that "you seem lost without your gang" as you
told me before?

Do you realize that /you/ are in the minority, when related to these groups?

I'm done. You're free to start over insulting me without any reasonable
motivation.

 

[Ian Collins]

Nope, I cannot accept it, because it is a number pulled out of thin air.

Give up, the bloke's an arse.

 

[news.virginmedia.com]

Nope, I cannot accept it, because it is a number pulled out of thin air.

Ok well lets use words in stead of numbers and say an overwhelming majority
of programmers across the globe think of this interpretation as what is
generally meant by input.
Would you accept this?

In the Oxford dictionary, one of the definitions of the word "input" is
"the action of putting something in". This is one of the general
/meanings/ of this word according to an authoritative source about the
English language. Further than that, we have a lot of different
/interpretations/ that are strictly tied to the context the word it is
used in.


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.

This is a forum about the C++ language /as defined/ by the C++ standard.

You don't seem to understand what this means.

This does not , as you imply, mean:
Any discussions on this forum shall be discussed in a context that is the
same context as the C++ standards.

From the "Read this first" of comp.lang.c++:

"First of all, please keep in mind that comp.lang.c++ is a group for
discussion of general issues of the C++ programming language, as defined
by the ANSI/ISO language standard"

Here the standard is normally taken for granted and not normally
questioned, there is a more fitting group for that: comp.std.c++

Nobody is questioning the standards. I question not only your interpretation
of the the meaning of the text in standards but also your interpretation of
the context in which the standards are delivered.

There are more fitting groups for "software engineering" in general.

Are you suggesting that all software engineering terms are OT on this forum?

Once more, I'd like to see your interpretation of the same about this
subject. In particular, once more, 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.

You already said this at top of your post to which I have replied that it's
not within the scope of the C++ standards.

I don't, but nothing would forbid me to if I wanted.

God forbid.

Read the "read me first" of this group, if you never did.


This group is /not/ about software engineering, it is about the C++
language.

The C++ programming language is a tool that is used in software engineering.
This group is for discussions related to the use of the C++ language.
Therefore this is very much a software engineering forum.
The fact that you have twisted the context of my words, to imply that I said
this forum was about software engineering in generally, is blatantly
apparent for all to see.

What should I say, now, that "you seem lost without your gang" as you told
me before?

No I am simply applying what you seem to think is conclusive proof. That
being whatever the majority think is correct

Do you realize that /you/ are in the minority, when related to these
groups?

If this were correct I would rather be in the majority of the overwhelming
number of programmers worldwide than few argumentative numbskulls on a
discussion forum who can't admit when they're wrong.

I'm done. You're free to start over insulting me without any reasonable
motivation.

You are trying to take the word input, as used in the context of the
standards, and apply it to a completely different situation. This is a
blatant misinterpretation.

 

[Francesco S. Carta]

Francesco S. Carta ha scritto:

[some trolling]

I'm done. You're free to start over insulting me without any
reasonable motivation.

Don't worry - this thread makes it very clear that you are one of the
most patient participants c.l.c++ has ever seen (which by the way
reinforces my belief that Italians are among the friendliest folks on
this planet).

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.

Stay tuned.

 

[Francesco S. Carta]

Ok well lets use words in stead of numbers and say an overwhelming
majority of programmers across the globe think of this interpretation as
what is generally meant by input.
Would you accept this?

Nope, once more, because it's just a very specific interpretation and
because you're still pulling numbers out of the thin air (in this case,
the number you're pulling is an implied percentage).

There are a lot of other steps rightfully called "input" by a competent
programmer, and you have no proof that this specific one is /the/
interpretation meant by the /majority/ of them.

In order to prove it, you'd need to count them and gather the opinion of
50% + 1 of them, which should amount to several thousands records at
least, if not a way higher figure. Have you got such a database at your
disposal?

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.

Also, from the text I snipped, you object to the fact of considering the
C++ standard as the sole an only topic to be discussed here.

Please correct the above statements of mine if they happen to be incorrect.

Assuming they are correct, I accept them, that's your point of view, and
actually, it's my point of view too: I've discussed about off-topic
arguments several times without any particular problem - at the same
time, I've recognized and explicitly marked those arguments as being
off-topic when related to the C++ standard.

Now let me ask you a couple of further questions:

Do you recognize that the context of the parashift.com C++ FAQ is the
C++ language /as defined by the C++ standard/?

Do you recognize that Francis Glassborow expressed his opinions in the
context of the C++ language /as defined by the C++ standard/?

 

[Rui Maciel]

You don't seem to understand what this means.

Do you even know what constitutes the C++ programming language?


Rui Maciel

 

[news.virginmedia.com]

Nope, once more, because it's just a very specific interpretation and
because you're still pulling numbers out of the thin air (in this case,
the number you're pulling is an implied percentage).

Was it 2 or 3 posts ago you said:
'No, please let me correct this. I fully accept these generic
interpretations - on the contrary, I've repeatedly stated that the word
"input" can, by all rights, be assigned to the process of the program
getting the data from an external source.'

Now you don't seem to accept this interpretation.
You do not seem to have a clear opinion.

There are a lot of other steps rightfully called "input" by a competent
programmer, and you have no proof that this specific one is /the/
interpretation meant by the /majority/ of them.

In order to prove it, you'd need to count them and gather the opinion of
50% + 1 of them, which should amount to several thousands records at
least, if not a way higher figure. Have you got such a database at your
disposal?

Actually I do.
http://www.google.co.uk/#hl=en&q=C+...1g-c1g2&aql=&oq=&gs_rfai=&fp=1e103a306e0305bf
start counting.

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.
This definition explains how the term 'diagnostic message' is used within
the standards. This does mean it would be incorrect to use this term outside
the standards in a different context.
In the list of definitions in the standards there is no definition of input.
This means the standards do not define the term input in any given context.
Is this correct ?

If the term input was defined by the standards it would be defined to give
the meaning whilst used within the context of the standards. It would not be
correct to apply this definition to all discussions related to C++ outside
the context for which it was intended.

Also, from the text I snipped, you object to the fact of considering the
C++ standard as the sole an only topic to be discussed here.

I don't object to you discussing the standards here, I am very flexible in
my discussions. But I object to you twisting the meaning of words that are
not defined by the C++ standards and interpreting them in such a way to make
it appear as if they are.

Please correct the above statements of mine if they happen to be
incorrect.

Assuming they are correct, I accept them, that's your point of view, and
actually, it's my point of view too: I've discussed about off-topic
arguments several times without any particular problem - at the same time,
I've recognized and explicitly marked those arguments as being off-topic
when related to the C++ standard.

I hope you are not implying that anything not defined by the standards is OT
because obviously this would be complete nonsense.
This is what I mean by you not understanding the term 'C++ language as
defined by the C++ standard'.
You seem to be interpreting this as..... The C++ language is defined by the
C++ Standards, and anything not defined by the standards has no place in the
C++ community.

Now let me ask you a couple of further questions:

Do you recognize that the context of the parashift.com C++ FAQ is the C++
language /as defined by the C++ standard/?

Do you recognize that Francis Glassborow expressed his opinions in the
context of the C++ language /as defined by the C++ standard/?

What you seem to be asking me here is if I think the C++ standard defines
the context in which we discuss C++.
Are you suggesting that the C++ standards define 'input' in the context FG
expressed it? If so I disagree.
If this is not what you mean please express what you mean more clearly.

 

[Francesco S. Carta]

Was it 2 or 3 posts ago you said:
'No, please let me correct this. I fully accept these generic
interpretations - on the contrary, I've repeatedly stated that the word
"input" can, by all rights, be assigned to the process of the program
getting the data from an external source.'

Now you don't seem to accept this interpretation.
You do not seem to have a clear opinion.

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.

Actually I do.
http://www.google.co.uk/#hl=en&q=C+...1g-c1g2&aql=&oq=&gs_rfai=&fp=1e103a306e0305bf

start counting.

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?

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.

In the list of definitions in the standards there is no definition of
input. This means the standards do not define the term input in any
given context.
Is this correct ?

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.

If the term input was defined by the standards it would be defined to
give the meaning whilst used within the context of the standards. It
would not be correct to apply this definition to all discussions related
to C++ outside the context for which it was intended.

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.

I don't object to you discussing the standards here, I am very flexible
in my discussions. But I object to you twisting the meaning of words
that are not defined by the C++ standards and interpreting them in such
a way to make it appear as if they are.

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

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.

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.

I hope you are not implying that anything not defined by the standards
is OT because obviously this would be complete nonsense.
This is what I mean by you not understanding the term 'C++ language as
defined by the C++ standard'.
You seem to be interpreting this as..... The C++ language is defined by
the C++ Standards, and anything not defined by the standards has no
place in the C++ community.

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.

What you seem to be asking me here is if I think the C++ standard
defines the context in which we discuss C++.

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.

Are you suggesting that the C++ standards define 'input' in the context
FG expressed it? If so I disagree.
If this is not what you mean please express what you mean more clearly.

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.

 

[Francesco S. Carta]

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.

I forgot a verb up there, the sentence should read:

[...] because your assertion means that some not better specified
"majority" would /agree/ on that interpretation of the word "input" as
being the "obvious one", and you cannot prove it.

 

[Francesco S. Carta]

He seems to be doing fine and setting an excellent example of keeping
cool in the face of completely undeserved insults.

Thank you very much for your words Francis, although I don't think I
deserve to be complimented that much [*].

Now a little detail about std::cin that you seem to have missed. Where
it gets the data is not necessarily from standard input. We can simply
supply it with a preloaded buffer, but we can also do much more but that
gets pretty complicated (see Standard C++ IOstreams and Locales by Kreft
& Langer) The significant point is that the Standard does not mean input
in the sense you mean when it refers to input functions because that
would require something that is not required to be true.

None of us are stupid enough to think that the way that the C++ Standard
uses input is the only way but when we are discussing C++ istreams it is
natural to use 'input' in the way that the C++ Standard uses them.

Now I will hand back to Francesco though perhaps it is time that he
accepted that you are a lost cause.

I'm still trying to ascertain if he is for real if he is just having fun.

I'm more on the "real" side, and I think that maybe one day he will
realize that it's not that bad to recognize to have been wrong and
present some sincere apologies. On my part, I would accept them.

[*] I'm going to do a test period for a new job where I'll be doing help
desk for a software (via tickets and via voice), I happen to look at
this as a free way to practice writing (for the tickets) and heat (for
the voice: I'll be getting quite a lot of misunderstandings because I'm
not a native speaker).

Heck, I think I would have been better keeping this undisclosed a bit
longer!

 

[news.virginmedia.com]

He seems to be doing fine and setting an excellent example of keeping cool
in the face of completely undeserved insults.

Now a little detail about std::cin that you seem to have missed. Where it
gets the data is not necessarily from standard input. We can simply supply
it with a preloaded buffer, but we can also do much more but that gets
pretty complicated (see Standard C++ IOstreams and Locales by Kreft &
Langer) The significant point is that the Standard does not mean input in
the sense you mean when it refers to input functions because that would
require something that is not required to be true.

If you are discussing input functions the input to the function is regarded
as input. If you are discussing streams, the input to the stream is regarded
as input.
When the standards use the term 'input' in the context of function input and
you apply this to a stream, you are either misinterpreting the standards or
deliberately misquoting.

None of us are stupid enough to think that the way that the C++ Standard
uses input is the only way but when we are discussing C++ istreams it is
natural to use 'input' in the way that the C++ Standard uses them.

The natural way to use 'input' is not take a quote from the standards, which
originally means input to function, and apply this to a stream object.
Using words in the context of the standards is only appropriate if you are
defining the language. As a software engineer designing a program the
wording in the standards is inappropriate.

 

[Francesco S. Carta]

If you are discussing input functions the input to the function is
regarded as input. If you are discussing streams, the input to the
stream is regarded as input.

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.

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

Do you realize that when you speak about "input to function" you are
speaking about the fact of passing parameters to it, are you?

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

When the standards use the term 'input' in the context of function input
and you apply this to a stream, you are either misinterpreting the
standards or deliberately misquoting.

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.

 

[Alf P. Steinbach /Usenet]

* 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++]?


TIA.,

- Alf

 

[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 ;-)