Francesco S Cartas CLEAR idea about input.
news.virginmedia.com
That other thread is getting a bit messy so I've started this new thread.
The purpose of this thread is to obtain what is your clear interpretation of
what "input" is , in the context of C++ streams.
Although I have expressed my opinion clearly you do not seem to capable of
this.
For example given your theory* that input is a step from one process to
another and using the -> notation I asked you:
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
You chose to avoid this.
You also refer to the correct meaning of input as extraction from a stream,
which in the above stepping theory would mean b. However if you use the
stepping theory it doesn't make sense to say input is extraction from a
strea. But if we disregard your stepping theory and we 'consider inPut as a
parcel' it is possible to say inPut is extracted from a stream and still
make perfectly good sense. I will use inPut with a capital P when it is
meant in this way. i.e. consider inPut in the noun form.
So lets say we extract inPut from a stream, then it must be assumed that the
stream first contains inPut.
So as you can see I have put forward a couple of ideas that may or may not
be your interpretation of input, but this is not YOUR opinion. So I ask you
to give your opinion in a clear and concise explanation, if you are capable
of such a simple task.
*ref:
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/7258acdd7e01b8d4
Francesco S. Carta
The post of mine you just linked clearly demonstrates my position, to
the point that any third person should be able to correctly answer, at
my place, to any of your questions.
I repeat it once more: the word "input" means just "the action of
putting something in". It has no other meaning unless you associate it
to something else.
[ Besides, it's technically impossible to pick an item from your list
without incurring in some error. Let's say I pick "f) change meaning
depending on the context" ]
In the context of "while (std::cin >> value) - how does this work?" the
word "input" refers to the action performed by the extractor, that is,
the action of putting data from the stream to the variable.
Now I've grown tired of you and I won't reply to you any more unless you
fully apologize to me and to all the other people that you have
gratuitously insulted during the last two weeks.
Any third person interested in the subject is encouraged to search
"pchristor yahoo.co.uk" in Google Groups to read what you posted these
last two weeks and understand what I'm referring to.
--
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:4c961f8e$0$30909$5fc...@news.tiscali.it...
It means as your post explains?
>
> I repeat it once more: the word "input" means just "the action of putting
> something in". It has no other meaning unless you associate it to
> something else.
Here you attempt to define input as a verb. You say 'it has no other
meaning' which is completely incorrect.
I can disprove your incorrect definition of input with the following link
http://www.audioenglish.net/dictionary/input.htm.
>
> [ Besides, it's technically impossible to pick an item from your list
> without incurring in some error. Let's say I pick "f) change meaning
> depending on the context" ]
The options I put forward in the list were based on your theory, as per ref
post.
I would like to quote from the said ref post what you concluded with:
"Now, the context of this thread was crystal clear from the start: we are
speaking of the last step of the input process, the passage from
std::cin to a variable. "
It is apparent that you are constantly contradicting yourself and twisting
your interpretations.
This is justification to assume that you are incapable of giving a clear and
concise explanation.
>
> In the context of "while (std::cin >> value) - how does this work?" the
> word "input" refers to the action performed by the extractor, that is, the
> action of putting data from the stream to the variable.
This is not an action of input from the perspective of the stream , this
would be considered input from the perspective of the variable.
The only way you can justify the input from stream is to consider inPut as a
noun.
However this completely contradicts what you have said in the previous
couple of paragraphs.
>
> Now I've grown tired of you and I won't reply to you any more unless you
> fully apologize to me and to all the other people that you have
> gratuitously insulted during the last two weeks.
>
> Any third person interested in the subject is encouraged to search
> "pchristor yahoo.co.uk" in Google Groups to read what you posted these
> last two weeks and understand what I'm referring to.
>
> --
> FSC - http://userscripts.org/scripts/show/59948
> http://fscode.altervista.org - http://sardinias.com
It seems you are indeed incapable of providing a clear and concise
explanation of your idea of input, in the context of C++ streams.
I think this is because you're afraid your reply will prove you a babbling
idiotic fool , or you are simply too stupid to communicate in such a way.
Francesco S. Carta
Yes, but don't worry, if you wasn't able to understand my point of view
from that post I'll eagerly explain it using a more rigorous wording
(heck, now that you have run away from the other threads, omitting to
reply to tens of questions of mine, I can happily stay here and start over).
And, please, if you feel you did not run away from there, go back there
and post your replies to my posts, the folks there at comp.lang.c++ have
not really understood the value of your contributions.
>>
>> I repeat it once more: the word "input" means just "the action of
>> putting something in". It has no other meaning unless you associate it
>> to something else.
>
> Here you attempt to define input as a verb. You say 'it has no other
> meaning' which is completely incorrect.
> I can disprove your incorrect definition of input with the following link
> http://www.audioenglish.net/dictionary/input.htm.
Point for you, indeed I meant to define it as a verb. Now that you're
starting to get somewhat technical, I feel this will get even more fun.
>>
>> [ Besides, it's technically impossible to pick an item from your list
>> without incurring in some error. Let's say I pick "f) change meaning
>> depending on the context" ]
>
> The options I put forward in the list were based on your theory, as per
> ref post.
> I would like to quote from the said ref post what you concluded with:
> "Now, the context of this thread was crystal clear from the start: we are
> speaking of the last step of the input process, the passage from
> std::cin to a variable. "
>
> It is apparent that you are constantly contradicting yourself and
> twisting your interpretations.
> This is justification to assume that you are incapable of giving a clear
> and concise explanation.
Oh please excuse me for that! I'll do my best to restate my point as
clearly and concisely as necessary to let you understand it.
>>
>> In the context of "while (std::cin >> value) - how does this work?"
>> the word "input" refers to the action performed by the extractor, that
>> is, the action of putting data from the stream to the variable.
>
> This is not an action of input from the perspective of the stream , this
> would be considered input from the perspective of the variable.
> The only way you can justify the input from stream is to consider inPut
> as a noun.
> However this completely contradicts what you have said in the previous
> couple of paragraphs.
>
>>
> > Now I've grown tired of you and I won't reply to you any more unless you
>> fully apologize to me and to all the other people that you have
>> gratuitously insulted during the last two weeks.
>>
>> Any third person interested in the subject is encouraged to search
>> "pchristor yahoo.co.uk" in Google Groups to read what you posted these
>> last two weeks and understand what I'm referring to.
>>
>> --
>> FSC - http://userscripts.org/scripts/show/59948
>> http://fscode.altervista.org - http://sardinias.com
>
> It seems you are indeed incapable of providing a clear and concise
> explanation of your idea of input, in the context of C++ streams.
> I think this is because you're afraid your reply will prove you a
> babbling idiotic fool , or you are simply too stupid to communicate in
> such a way.
I notice that you're starting over insulting me, that's nice. I was
missing your insults, somewhat.
Aaaaaaall right, you want me to define what I mean with the word "input"
in the context of C++ streams, that's it?
After that I explain to you my point of view, if I happen to succeed and
get it across, I hope you will be so kind to reply to my questions,
finally.
The word "input", as you teach me, can be interpreted as a noun or as a
verb. As a noun, it represents the data that gets putted into something.
As a verb, it represents the action of putting that data into something.
At the same time, we have the word "output". As a noun, it represents
the data that gets sent out of something. As a verb, it represents the
action of sending that data out.
So, when we analyse the "std::cin >> variable" expression, we see two
objects and an operator.
That operator is defined as a member function named "operator>>()" and
the above expression resolves in a call like this one:
"std::cin.operator>>(variable).
When executed, that function does a specific action that can be
described with either of these two sentences:
- it performs an input (verb) because it puts some input (noun) /in/to a
variable
- it performs an output (verb) because it sends some output (noun) /out/
from the stream
Since it's misleading to say that the member functions of an "input
stream" such as std::cin perform an output (verb), the standard stick to
the idea that those functions perform an input (verb) and it calls them
as "input functions" (noun).
Just so you'd know, /objects/ don't do anything, and a stream such as
std::cin is an object. All the actions on that stream get performed by
some function.
Does the above suffice to reply to your question? Let's see your next move.
Don't forget that, after we will have clarified all of this, we need to
go back to the first two posts of yours in the thread "while (std::cin
>> value) - how does this work?", where it all started.
Rui Maciel
> Francesco,
> That other thread
<snip/>
Is a pure waste of bandwidth.
People, please don't feed the troll.
Rui Maciel
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c964e2b$0$30913$5fc...@news.tiscali.it...
If you feel I have 'run away' from any other points you have raised , feel
free to raise them in a new thread. Please do not
introduce them here in an attempt to obfuscate this thread.
>>>
>>> I repeat it once more: the word "input" means just "the action of
>>> putting something in". It has no other meaning unless you associate it
>>> to something else.
>>
>> Here you attempt to define input as a verb. You say 'it has no other
>> meaning' which is completely incorrect.
>> I can disprove your incorrect definition of input with the following link
>> http://www.audioenglish.net/dictionary/input.htm.
>
> Point for you, indeed I meant to define it as a verb. Now that you're
> starting to get somewhat technical, I feel this will get even more fun.
>
I have always been technical , perhaps from your point of view the
discussion has not been technical.
>>>
>>> [ Besides, it's technically impossible to pick an item from your list
>>> without incurring in some error. Let's say I pick "f) change meaning
>>> depending on the context" ]
>>
>> The options I put forward in the list were based on your theory, as per
>> ref post.
>> I would like to quote from the said ref post what you concluded with:
>> "Now, the context of this thread was crystal clear from the start: we are
>> speaking of the last step of the input process, the passage from
>> std::cin to a variable. "
>>
>> It is apparent that you are constantly contradicting yourself and
>> twisting your interpretations.
>> This is justification to assume that you are incapable of giving a clear
>> and concise explanation.
>
> Oh please excuse me for that! I'll do my best to restate my point as
> clearly and concisely as necessary to let you understand it.
>
Seems you somewhat accept this.
Just get on with it.
>
> The word "input", as you teach me, can be interpreted as a noun or as a
> verb. As a noun, it represents the data that gets putted into something.
> As a verb, it represents the action of putting that data into something.
>
Ok
> At the same time, we have the word "output". As a noun, it represents the
> data that gets sent out of something. As a verb, it represents the action
> of sending that data out.
Don't see the need to write this but whatever.
>
> So, when we analyse the "std::cin >> variable" expression, we see two
> objects and an operator.
>
> That operator is defined as a member function named "operator>>()" and the
> above expression resolves in a call like this one:
> "std::cin.operator>>(variable).
The operator>> is a method of the stream object, ok.
>
> When executed, that function does a specific action that can be described
> with either of these two sentences:
> - it performs an input (verb) because it puts some input (noun) /in/to a
> variable
> - it performs an output (verb) because it sends some output (noun) /out/
> from the stream
>
> Since it's misleading to say that the member functions of an "input
> stream" such as std::cin perform an output (verb), the standard stick to
> the idea that those functions perform an input (verb) and it calls them as
> "input functions" (noun).
You state above:
"the standard stick to the idea that those functions perform an input
(verb)"
This is surely incorrect, as many of the input functions do not perform
input(verb), they may perform an operation on an inPut (noun).
I believe the section of the standards you refer to is:
"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. "
The term 'input characters' here is not used in the verb form as you seem to
think.
And also note that it says "input functions are described AS IF they obtain
(or extract) input characters".
It is evident that your interpretation of the standards is nowhere close to
what the Standards clearly state.
>
> Just so you'd know, /objects/ don't do anything, and a stream such as
> std::cin is an object. All the actions on that stream get performed by
> some function.
Not quite true.
Consider the very simple example of an Object Constructor that assigns a
parameter to a member variable.
Yes we all know a constructor is function but because this function is an
integral part of an object it can be taken that the operation is carried out
by the object.
I think it a bad idea to take the view that 'objects do nothing' , OOP
revolves around the concept of objects carrying out operations and this is
why a disagree with you.
Here's a general link that supports my idea of OPP, please read this over
and consider your actions carefully before you try and create a new argument
over this:
http://en.wikipedia.org/wiki/Object-oriented_programming
>
> Does the above suffice to reply to your question? Let's see your next
> move.
>
> Don't forget that, after we will have clarified all of this, we need to go
> back to the first two posts of yours in the thread "while (std::cin
> >> value) - how does this work?", where it all started.
>
> --
I think I have provided enough evidence to rest my case but if you feel
unsatisfied with my comments please feel free to reply.
Francesco S. Carta
Oh, he is not a troll, he is for real! He is truly convinced of the
points he carries!
But don't worry, two hours more and I'll stop interacting with him (it's
22:03 here, so my last reply to him will be within midnight).
Despite of what he says, I think he's learning a lot :-)
Francesco S. Carta
As you prefer. Just consider that there are several places and issues
where you're leaving me "the last word".
Oh, no, don't be pressed, I promised not to reply to your posts after
midnight (just one hour and ten minutes left), so you can leave those
replies for later, when I won't be allowed to reply any more.
>>>>
>>>> I repeat it once more: the word "input" means just "the action of
>>>> putting something in". It has no other meaning unless you associate it
>>>> to something else.
>>>
>>> Here you attempt to define input as a verb. You say 'it has no other
>>> meaning' which is completely incorrect.
>>> I can disprove your incorrect definition of input with the following
>>> link
>>> http://www.audioenglish.net/dictionary/input.htm.
>>
>> Point for you, indeed I meant to define it as a verb. Now that you're
>> starting to get somewhat technical, I feel this will get even more fun.
>>
> I have always been technical , perhaps from your point of view the
> discussion has not been technical.
Exactly, you carried over a lot of imprecision and imaginary facts.
>>>>
>>>> [ Besides, it's technically impossible to pick an item from your list
>>>> without incurring in some error. Let's say I pick "f) change meaning
>>>> depending on the context" ]
>>>
>>> The options I put forward in the list were based on your theory, as per
>>> ref post.
>>> I would like to quote from the said ref post what you concluded with:
>>> "Now, the context of this thread was crystal clear from the start: we
>>> are
>>> speaking of the last step of the input process, the passage from
>>> std::cin to a variable. "
>>>
>>> It is apparent that you are constantly contradicting yourself and
>>> twisting your interpretations.
>>> This is justification to assume that you are incapable of giving a clear
>>> and concise explanation.
>>
>> Oh please excuse me for that! I'll do my best to restate my point as
>> clearly and concisely as necessary to let you understand it.
>>
> Seems you somewhat accept this.
Sure I do, I cannot pretend you to be smart enough to infer context and
implications from my writings, I must explicitly point out and define
almost every single technical word I use for you to "catch" it.
Recall this point, you just said "Ok" to my definition of input as a
verb: it represents the action of putting some data into something.
I wonder if you'll object to my rephrasing, I look forward.
This is a proof of how clueless you are and of how hard you need to
start filling the gaps of your knowledge.
You agreed to the definition of "input" as a verb as the action of
putting some data into something: "input functions" put data into a
variable, hence they perform "input" as a verb.
Of course, the data they operate on is "input" as a noun. You cannot
have input as a verb without input as a noun: the whole operation, by
definition, implies the usage of both concepts.
> I believe the section of the standards you refer to is:
> "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. "
>
> The term 'input characters' here is not used in the verb form as you
> seem to think.
That doesn't really change nothing. The important thing is the concept
it expresses, not the actual wording.
"Ride the bike for a while" and "get a ride on the bike" express the
same concept, despite of the fact that "ride" is a verb in one sentence
and a noun in the other. Consider taking some serious English language
lessons.
> And also note that it says "input functions are described AS IF they
> obtain (or extract) input characters".
Ehehhe, you capitalized the words "as if" as if they change anything.
The important thing the standard is telling us is the /logical/
operation performed by those functions. The /actual/ operations
performed by those functions depend on the implementation.
> It is evident that your interpretation of the standards is nowhere close
> to what the Standards clearly state.
I must say that your extreme mastering of the English language makes it
a snap, for you, to understand the contents of a trivial document as the
C++ Standard, and you're giving us very unobjectionable proof of this.
>>
> > Just so you'd know, /objects/ don't do anything, and a stream such as
>> std::cin is an object. All the actions on that stream get performed by
>> some function.
> Not quite true.
Ah! Where it all started! Tell me, was that a "tongue in cheek"
statement once more, or are you saying there is something wrong with my
paragraph above?
> Consider the very simple example of an Object Constructor that assigns a
> parameter to a member variable.
> Yes we all know a constructor is function but because this function is
> an integral part of an object it can be taken that the operation is
> carried out by the object.
Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
> I think it a bad idea to take the view that 'objects do nothing' , OOP
> revolves around the concept of objects carrying out operations and this
> is why a disagree with you.
> Here's a general link that supports my idea of OPP, please read this
> over and consider your actions carefully before you try and create a new
> argument over this:
> http://en.wikipedia.org/wiki/Object-oriented_programming
I don't care about your idea of OOP:
THIS
IS
SPARTAAAA!
Ouch, no, I meant to say: this is Standard C++, therefore that wikipedia
page has no normative value (did you look "normative" up in your
dictionary yet?).
One hour and ten minutes left.
news.virginmedia.com
"Francesco S. Carta" <entu...@gmail.com> wrote in message
news:4c9677b0$0$6822$5fc...@news.tiscali.it...
How convenient that should be "unable" to post after midnight.
Maybe more of a case that you're just slithering away into the darkness.
>>>>>
>>>>> I repeat it once more: the word "input" means just "the action of
>>>>> putting something in". It has no other meaning unless you associate it
>>>>> to something else.
>>>>
>>>> Here you attempt to define input as a verb. You say 'it has no other
>>>> meaning' which is completely incorrect.
>>>> I can disprove your incorrect definition of input with the following
>>>> link
>>>> http://www.audioenglish.net/dictionary/input.htm.
>>>
>>> Point for you, indeed I meant to define it as a verb. Now that you're
>>> starting to get somewhat technical, I feel this will get even more fun.
>>>
>> I have always been technical , perhaps from your point of view the
>> discussion has not been technical.
>
> Exactly, you carried over a lot of imprecision and imaginary facts.
>
A false accusation that lacks any support or evidence.
>>>>>
>>>>> [ Besides, it's technically impossible to pick an item from your list
>>>>> without incurring in some error. Let's say I pick "f) change meaning
>>>>> depending on the context" ]
>>>>
>>>> The options I put forward in the list were based on your theory, as per
>>>> ref post.
>>>> I would like to quote from the said ref post what you concluded with:
>>>> "Now, the context of this thread was crystal clear from the start: we
>>>> are
>>>> speaking of the last step of the input process, the passage from
>>>> std::cin to a variable. "
>>>>
>>>> It is apparent that you are constantly contradicting yourself and
>>>> twisting your interpretations.
>>>> This is justification to assume that you are incapable of giving a
>>>> clear
>>>> and concise explanation.
>>>
>>> Oh please excuse me for that! I'll do my best to restate my point as
>>> clearly and concisely as necessary to let you understand it.
>>>
>> Seems you somewhat accept this.
>
> Sure I do, I cannot pretend you to be smart enough to infer context and
> implications from my writings, I must explicitly point out and define
> almost every single technical word I use for you to "catch" it.
>
You don't appear to be capable of defining any word whether it be technical
or not.
Err I was acknowledging the fact that I'd taught you something new.
An "input function" CAN perform input(verb) but does not always.
In the case of inputting to a variable this verb is considered input from
the variables perspective but not from the perspective of the stream.
>
> Of course, the data they operate on is "input" as a noun. You cannot have
> input as a verb without input as a noun: the whole operation, by
> definition, implies the usage of both concepts.
>
>> I believe the section of the standards you refer to is:
>> "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. "
>>
>> The term 'input characters' here is not used in the verb form as you
>> seem to think.
>
> That doesn't really change nothing. The important thing is the concept it
> expresses, not the actual wording.
It does change something , it proves that you misinterpret the standards to
mean something it doesn't.
>
> "Ride the bike for a while" and "get a ride on the bike" express the same
> concept, despite of the fact that "ride" is a verb in one sentence and a
> noun in the other. Consider taking some serious English language lessons.
Dunno what this nonsense is about.
>
>> And also note that it says "input functions are described AS IF they
>> obtain (or extract) input characters".
>
> Ehehhe, you capitalized the words "as if" as if they change anything.
They do change something, they change the meaning of the text.
>
> The important thing the standard is telling us is the /logical/ operation
> performed by those functions. The /actual/ operations performed by those
> functions depend on the implementation.
>
I have just proven that you misinterpreted the standards yet you insist on
acting like some authority to tell us what the standards define.
>> It is evident that your interpretation of the standards is nowhere close
>> to what the Standards clearly state.
>
> I must say that your extreme mastering of the English language makes it a
> snap, for you, to understand the contents of a trivial document as the C++
> Standard, and you're giving us very unobjectionable proof of this.
>
A trivial document ?
>>>
>> > Just so you'd know, /objects/ don't do anything, and a stream such as
>>> std::cin is an object. All the actions on that stream get performed by
>>> some function.
>> Not quite true.
>
> Ah! Where it all started! Tell me, was that a "tongue in cheek" statement
> once more, or are you saying there is something wrong with my paragraph
> above?
>
>> Consider the very simple example of an Object Constructor that assigns a
>> parameter to a member variable.
>> Yes we all know a constructor is function but because this function is
>> an integral part of an object it can be taken that the operation is
>> carried out by the object.
>
> Extremely wrong. Functions are NOT part of an object.
Do you really mean this? or have you made a typo?
Perhaps you are a bit tired and are not thinking straight?
>
> Remember that we are speaking in the context of the C++ Standard, where an
> "object" is defined as a region of storage:
>
> <citation>
> 1.8 The C+ + object model [intro.object]
> 1 The constructs in a C++ program create, destroy, refer to, access, and
> manipulate objects. An object is a region of storage. [Note: A function is
> not an object, regardless of whether or not it occupies storage in the way
> that objects do. ]
> </citation>
>
Are you now trying to imply that this states an object cannot contain member
functions?
I think you're making a really good job of convincing people that you are
definitely not an authority to quote from the standards.
The above quote states that "A function is not an object", you seem to be
misinterpreting this to mean an object cannot contain member functions.
> Please find me a quote from the standard that expresses the same concept
> of this extremely wrong sentence of yours: "function is an integral part
> of an object".
The standards is not written for the purpose of explaining OOP. Therefore it
would be the wrong document to reference.
I think the onus rests on you to find a quote that disproves it.
>
> You wanted to get technical, didn't you? Chapter and verse please.
>
I think its quite clear you have not took my advice re:
"consider your actions carefully before you try and create a new argument
over this".
>> I think it a bad idea to take the view that 'objects do nothing' , OOP
>> revolves around the concept of objects carrying out operations and this
>> is why a disagree with you.
>> Here's a general link that supports my idea of OPP, please read this
>> over and consider your actions carefully before you try and create a new
>> argument over this:
>> http://en.wikipedia.org/wiki/Object-oriented_programming
>
> I don't care about your idea of OOP:
Apparently.
>
> THIS
> IS
> SPARTAAAA!
>
> Ouch, no, I meant to say: this is Standard C++, therefore that wikipedia
> page has no normative value (did you look "normative" up in your
> dictionary yet?).
It seems as though normative is a new word in your English vocabulary? I
learned that word about 40 years ago , if you must know.
>
> One hour and ten minutes left.
>
> --
Maybe you should get some sleep.
Andreas
> But don't worry, two hours more and I'll stop interacting with him (it's
> 22:03 here, so my last reply to him will be within midnight).
>
> Despite of what he says, I think he's learning a lot :-)
I don't have the impression. At the moment he don't take lession in C-C
++. But it would be more worth to learn in politeness and manners. If
I need some helpful answer, especially input for discussion with
others, I frankly would accept, that I may be wrong.
I learnd science is when you doubt your own meaning. When you keep
position without the choice for change, it's absolutism.
Andreas