input to cin
news.virginmedia.com
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
Christian Hackl
> 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.
Quite a few problems in software engineering are of social nature... :)
> These people insist that the term "input" with regards to the " cin>>object"
> expression means the stage where some value is assigned to object.
"input" is such a general term in software engineering that this
question becomes moot. It's hair-splitting, really. The important
question is more along the lines of: "Did my attempt to get a value from
the stream fail or is the object now safe to use?"
Leave the theory of Ideas ("what is true input?") to Platonism.
> 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;
A better way to do this is to use std::getline and then check the first
character of the line, plus some error handling for illegal input.
> while (x < 1 || x > 9)
That's not really a to z...
> {
> 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.
If someone enters the character 'A', then std::cin will go into a failed
state and nothing will be assigned to the variable. However, in order to
check the character the program obviously had to read it from the
stream. After all, how could you possibly check for a wrong value
without actually reading anything?
In this sense, input did happen, of course, because an external resource
(e.g. a keyboard) was queried by the system. I'm sure "these people"
would not argue that.
On the other hand, if you define "input" as the entire process up until
the object getting assigned a value, then no input happened because that
process is interrupted.
> 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.
Just calm down! It's not worth getting annoyed about. You are both right :)
--
Christian Hackl
ha...@sbox.tugraz.at
Milano 2008/2009 -- L'Italia chiamň, sě!
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.
--
Ben.
news.virginmedia.com
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:0.2d680f5955b30d15c132.2010...@bsb.me.uk...
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?
>
>> {
>> 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.
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 :P)
or
d) switch the context when it suits.
or
e) neither of the above
I leave it for you to decide.
Christian Hackl
> 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.
If that's what you mean by "successful".
> There is only one input operation here so it should be clearer.
Actually, there are two input operations: operator>> and get().
> If the input was unsuccessful I wouldn't be able to process it.
It was unsuccessful and yet you could process something. Strange? No, it
merely indicates that the discussion is about terminology, not substance.
> 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 :P)
> or
> d) switch the context when it suits.
> or
> e) neither of the above
f) all of the above.
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
"Ike Naar" <i...@sdf.lonestar.org> wrote in message
news:slrn3vfsi94...@sdf.lonestar.org...
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
"Christian Hackl" <christi...@student.tugraz.at> wrote in message
news:i6te6s$s5h$1...@news.eternal-september.org...
You don't make sense.
Plonk.
Keith Thompson
[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.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
news.virginmedia.com
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnmxrhi...@nuthaus.mib.org...
> "news.virginmedia.com" <pchr...@yahoo.co.uk> writes:
> [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.
Christian Hackl
> "news.virginmedia.com" <pchr...@yahoo.co.uk> writes:
> [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.
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).
Keith Thompson
It's more about your attitude than about the words you use to express it.
news.virginmedia.com
"Christian Hackl" <ha...@sbox.tugraz.at> wrote in message
news:i6tpq9$hju$1...@news.eternal-september.org...
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
"Keith Thompson" <ks...@mib.org> wrote in message
news:lnaanhi...@nuthaus.mib.org...
> "news.virginmedia.com" <pchr...@yahoo.co.uk> writes:
>> "Keith Thompson" <ks...@mib.org> wrote in message
>> news:lnmxrhi...@nuthaus.mib.org...
>>> "news.virginmedia.com" <pchr...@yahoo.co.uk> writes:
>>> [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
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:0.2d680f5955b30d15c132.2010...@bsb.me.uk...
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
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:
Paul <pchr...@yahoo.co.uk> wrote:
> "Francesco S. Carta" <entu...@gmail.com> wrote:
>> Paul <pchr...@yahoo.co.uk> wrote:
>>> "Francis Glassborow" <francis.g...@btinternet.com> wrote:
>>>
>>>> Or to put it simply, std::cin >> value evaluates as true as long as
>>>> the input is successful. If the input operation fails for any
>>>> reason then the expression will evaluate as false.
>>>>
>>>> So the code can be read as 'as long as input succeeds ...
>>>>
>>>
>>> Not Quite true according to this :
>>> http://www.parashift.com/c++-faq-lite/input-output.html#faq-15.4
>>>
>>
>> You have either misunderstood the FAQ or Francis' simple
>> explanation, because they both express the same correct concept.
>>
> Input can succeed but that expression evaluate to false.
> As I said ... "Not Quite".
> Pretty pedantic but I wasn't pushing that point , just posting the
> link.
>
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!
--
FSC - http://userscripts.org/scripts/show/59948
http://fscode.altervista.org - http://sardinias.com
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c933945$0$6838$5fc...@news.tiscali.it...
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
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.
>
>
>> 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.
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:
<quote>
> 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?
</quote>
> 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.
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 :)
>
>>
>> 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?
Please cite the exact message where I've insulted you.
>> 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.
>
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c93499a$0$6823$5fc...@news.tiscali.it...
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?
>
>> 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.
>
> 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.
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.
>
> <quote>
> > 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?
> </quote>
>
>> 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.
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.
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 :)
>
>> 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?
>
> Please cite the exact message where I've insulted you.
I find your general disdaining manner quite insulting.
>
>>> 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.
>>
>
> 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
>
>
> "Francesco S. Carta" <entu...@gmail.com> wrote in message
> news:4c93499a$0$6823$5fc...@news.tiscali.it...
>> news.virginmedia.com <pchr...@yahoo.co.uk>, on 17/09/2010 11:30:30,
>> wrote:
>>
>>>
>>>
>>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>>> news:4c933945$0$6838$5fc...@news.tiscali.it...
>>>> news.virginmedia.com <pchr...@yahoo.co.uk>, on 17/09/2010 09:39:24,
>>>> wrote:
<snip>
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.
>>
>>> 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.
>>
>> 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.
> 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.
>> 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.
>
>>
>> <quote>
>> > 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?
>> </quote>
>>
>>> 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.
>
> 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.
>>
>> Once more, to the eyes of the Standard, an extractor IS an input
>> function. Period.
>
> 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.
>>
>>> 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?
>>
>> Please cite the exact message where I've insulted you.
>
> 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.
>>
>>>> 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.
>>>
>>
>> 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.
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c9368d9$0$6823$5fc...@news.tiscali.it...
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.
This is program input, we were discussing input in the context of streams.
>
>>> 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.
>>
>>>
>>> <quote>
>>> > 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?
>>> </quote>
>>>
>>>> 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.
>>
>> 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.
We obviously disagree on what input means with regards streams.
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.
>>>
>>> Once more, to the eyes of the Standard, an extractor IS an input
>>> function. Period.
>>
>> 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.
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::operator>>() '
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.
>
>>>
>>>> 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?
>>>
>>> Please cite the exact message where I've insulted you.
>>
>> 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 just insulted me again by misquoting my text in an attempt to downgrade
me.
>
>>>
>>>>> 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.
>>>>
>>>
>>> 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.
>
> 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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c93b0d7$0$30906$5fc...@news.tiscali.it...
> news.virginmedia.com <pchr...@yahoo.co.uk>, on 17/09/2010 17:41:23,
> wrote:
>
>> 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"?
>
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?
Francesco S. Carta
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c93dd94$0$6830$5fc...@news.tiscali.it...
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.
Francis Glassborow
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. 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. 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.
Francesco S. Carta
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
> news.virginmedia.com <pchr...@yahoo.co.uk>, on 18/09/2010 00:21:14,
> wrote:
>> 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.
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
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:N9GdnXZxLZIimAnR...@bt.com...
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c941a17$0$6843$5fc...@news.tiscali.it...
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.
>
>> 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
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
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.
>
>>
>>> 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
>
> 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++
>
>> 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.
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.
>
>> 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.
I don't, but nothing would forbid me to if I wanted.
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
> news.virginmedia.com <pchr...@yahoo.co.uk>, on 18/09/2010 10:24:55,
> wrote:
>>
>> 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.
Give up, the bloke's an arse.
--
Ian Collins
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c948d69$0$6820$5fc...@news.tiscali.it...
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?
>
>> 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.
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.
>
>> But I'll leave it.
>>
>>>
>>>> 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
>>
>> 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.
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.
>>
>>> 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.
>
> There are more fitting groups for "software engineering" in general.
Are you suggesting that all software engineering terms are OT on this forum?
>
>> 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.
>
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.
>>
>>> 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.
>
> I don't, but nothing would forbid me to if I wanted.
God forbid.
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.
>
>> 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?
>
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
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 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.
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
>>> 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.
>
> You don't seem to understand what this means.
Do you even know what constitutes the C++ programming language?
Rui Maciel
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c94b3eb$0$30912$5fc...@news.tiscali.it...
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%2B%2B+input+stream&aq=f&aqi=g1g-c1g2&aql=&oq=&gs_rfai=&fp=1e103a306e0305bf
start counting.
>
>>>
>>>> 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.
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.
news.virginmedia.com
"Rui Maciel" <rui.m...@gmail.com> wrote in message
news:4c94c118$0$9533$a729...@news.telepac.pt...
-2- C++ is a general purpose programming language based on the C programming
language as described in ISO/IEC 9899:1990 Programming languages - C
(intro.refs). In addition to the facilities provided by C, C++ provides
additional data types, classes, templates, exceptions, namespaces, inline
functions, operator overloading, function name overloading, references, free
store management operators, and additional library facilities.
HTH
Thx.
Francesco S. Carta
>
>
> "Francesco S. Carta" <entu...@gmail.com> wrote in message
> news:4c94b3eb$0$30912$5fc...@news.tiscali.it...
>> news.virginmedia.com <pchr...@yahoo.co.uk>, on 18/09/2010 12:11:09,
>> wrote:
>>
>>>
>>>
>>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>>> news:4c948d69$0$6820$5fc...@news.tiscali.it...
>>>> news.virginmedia.com <pchr...@yahoo.co.uk>, on 18/09/2010 10:24:55,
>>>> wrote:
>>>>
<large snip, see previous posts if necessary>
>>>>> 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.
>>>
>>> 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).
>>
> 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.
>> 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%2B%2B+input+stream&aq=f&aqi=g1g-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?
>>
>>>>
>>>>> 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.
> 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.
>>
>> 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.
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.
>>
>> 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.
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.
>> 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++.
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.
--
Francis Glassborow
>
>
> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>>> 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?
>
> You seem lost without your gang.
>
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.
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.
Francesco S. Carta
19:51:47, wrote:
> On 17/09/2010 12:33, news.virginmedia.com wrote:
>>
>>
>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>
>>>> 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?
>>
>> You seem lost without your gang.
>>
> 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
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:pK-dnYJYpZVelwjR...@bt.com...
> On 17/09/2010 12:33, news.virginmedia.com wrote:
>>
>>
>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>
>>>> 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?
>>
>> You seem lost without your gang.
>>
> 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
>
>
> "Francis Glassborow" <francis.g...@btinternet.com> wrote in
> message news:pK-dnYJYpZVelwjR...@bt.com...
>> On 17/09/2010 12:33, news.virginmedia.com wrote:
>>>
>>>
>>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>>
>>>>> 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?
>>>
>>> You seem lost without your gang.
>>>
>> 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.
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::ostream" (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
Hey, can you guys please stop cross-posting to [comp.lang.c++]?
TIA.,
- Alf
--
blog at <url: http://alfps.wordpress.com>
Francesco S. Carta
> * Francesco S. Carta, on 19.09.2010 00:58:
>> news.virginmedia.com <pchr...@yahoo.co.uk>, 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 ;-)
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c94f819$0$30893$5fc...@news.tiscali.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!
>
>>> 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%2B%2B+input+stream&aq=f&aqi=g1g-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?
>
And who wrote these technical texts on computer programming? Obvious nothing
to do with programmers, that would be too simple for you.
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.
>
>> 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.
This is talking about function input. Do you not understand the difference
between function input and stream input?
>
>> 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.
?
>
>>>
>>> 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.
>
> 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.
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c954425$0$30893$5fc...@news.tiscali.it...
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.
Yeah so you imply you are capable of deriving a stream class and overloading
operators, and does this make you super?
>> 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.
>
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c955434$0$30913$5fc...@news.tiscali.it...
> news.virginmedia.com <pchr...@yahoo.co.uk>, on 19/09/2010 00:45:10,
> wrote:
>
>> 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.
>
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" <entu...@gmail.com> wrote in message
news:4c954b36$0$6843$5fc...@news.tiscali.it...
phsyco killer verse 2
Francesco S. Carta
I'll take that as a compliment :-)
Francesco S. Carta
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?
>>
>> 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.
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".
>
>
>> 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.
That response has no meaning.
Can you tell me the difference between "input to function" and "input
function"?
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.
>>> 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.
>>
> 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
>
>
> "Francesco S. Carta" <entu...@gmail.com> wrote in message
> news:4c955434$0$30913$5fc...@news.tiscali.it...
>> news.virginmedia.com <pchr...@yahoo.co.uk>, on 19/09/2010 00:45:10,
>> wrote:
>>
>>> 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.
>>
> 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.
>> 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.
Indeed I may, I have learnt a lot of things so far.
Francesco S. Carta
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".
>
>>
>>>> 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%2B%2B+input+stream&aq=f&aqi=g1g-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?
>>
> 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.
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.
>>
>>> 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.
>
> 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.
>>
>>> 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.
>
> ?
What is the word that you happen to be missing in that sentence,
"normative" perhaps?
>>
>>>>
>>>> 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.
>>
>> 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.
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.
>> 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's /you/ who has to back up /your/ assertions. Chapter and verse, please.
>>
>> 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?
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).
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
"Ian Collins" <ian-...@hotmail.com> wrote in message
news:8fjisv...@mid.individual.net...
Totally
But I'm going prove the idiot is nothing more that a twisted little worm,
Thx.
Francesco S. Carta
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
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c95dd8d$0$30911$5fc...@news.tiscali.it...
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".
>
>>
>>
>>> 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.
>
> 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
you say that creating a stream class is basic , hmm interesting.
>>>> 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.
>>>
>> 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.
>
Why didn't you simply say... you don't know what your speaking about ?
>> 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.
>
> --
I think we should abort this branch of the thread as the other branch
addresses all these issues.
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c95df8a$0$30909$5fc...@news.tiscali.it...
Funny how you imply that I don't understand these two concepts when It was
me who initially pointed it out.
>
>>
>>>
>>>>> 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%2B%2B+input+stream&aq=f&aqi=g1g-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?
>>>
>> 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.
>
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.
So what is the difference between 'function input' and 'input to function'?
>>>
>>>> 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.
>>
>> ?
>
> 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 .
>>>
>>>>>
>>>>> 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.
>>>
>>> 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.
>
> 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.
>
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.
>>> 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'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?
>>>
>>> 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?
>
> 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).
>
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.
Here is the conversation from the original thread:
<snippet myText='>'>
> 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.
>> 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.
>
Another random put-down that lacks any real proof or evidence.
>>
>> 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.
>
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?
>> 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.
>
You'll find it's you who lacks understanding
> Your turn.
news.virginmedia.com
<snip>
>
> To say the data was input from the stream is simply wrong.
>
I must clarify I use input as a verb in this statement.
news.virginmedia.com
"Ben Bacarisse" <ben.u...@bsb.me.uk> wrote in message
news:0.2d680f5955b30d15c132.2010...@bsb.me.uk...
> "news.virginmedia.com" <pchr...@yahoo.co.uk> writes:
>
> 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.
>
> --
> Ben.
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
wrote:
>
> 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
"嘱 Tiib" <oot...@hot.ee> wrote in message
news:9dcfd94c-9d71-494c...@w4g2000vbh.googlegroups.com...
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.