technical correctness
Paul
He tried to wangle the term input to mean some bullshit it doesn't mean.
He tried to misquote text from the standards to mean something it wasn't
supposed to mean .
What is the point of these forums if we have no respect for technical
correctness?
When he is wrong but will not, and cannot, admit he is wrong, he can be
nothing more than a wanking idiot.
Michael Doubez
> I had an argument with some guy called Francis Glasssboro.
You must mean Francis Glassborow.
> He tried to wangle the term input to mean some bullshit it doesn't mean.
> He tried to misquote text from the standards to mean something it wasn't
> supposed to mean .
So you seem to think.
>
> What is the point of these forums if we have no respect for technical
> correctness?
Bickering ... ehhh ... Discussion
> When he is wrong but will not, and cannot, admit he is wrong, he can be
> nothing more than a wanking idiot.
If you think he cannot, then what's the point ? Working with others'
limitations is part of social life.
Concerning Francis Glassborow, I know him only from his work at the
ACCU but what I have seen of him doesn't fit with what you describes.
He is also a former teacher and has written a book about C++ for
beginner (with good reviews) which speaks for him.
Maybe you could reconsider the presence of a blind spot in your
reasonning.
--
Michael
Nick Keighley
> I had an argument with some guy called Francis Glasssboro.
> He tried to wangle the term input to mean some <nonsense> it doesn't mean.
> He tried to misquote text from the standards to mean something it wasn't
> supposed to mean .
>
> What is the point of these forums if we have no respect for technical
> correctness?
> When he is wrong but will not, and cannot, admit he is wrong, he can be
> nothing more than a <expletive> idiot.
where was this discussion? I couldn't find it with google. Francis is
usually pretty sensible. Perhaps we should be able to judge for
ourselves the quality of the post you refer to.
Umut Tabak
> When he is wrong but will not, and cannot, admit he is wrong, he can be
> nothing more than a wanking idiot.
This is a strong one, himself will come into play I suppose.
I am not very sure, but he sometimes posts on this forum and he does not
seem like a guy that could go hard on people...
He is the author of an introductory C++ book also, so reasonably
speaking, he should have a teacher side as well...
Best wishes,
U.
Ulrich Eckhardt
> I had an argument with some guy [...] He tried to wangle the term input
> to mean some bullshit it doesn't mean. He tried to misquote text from
> the standards to mean something it wasn't supposed to mean .
All this happens. The Usenet is a place where people find a forum for
discussion. Different interpretations of things like the C++ standard are
a common topic which people bring up to get a better (and peer-reviewed)
understanding of it.
> When he is wrong but will not, and cannot, admit he is wrong, he can
> be nothing more than a wanking idiot.
You don't have anything like a right that guarantees you that if someone
else is wrong they have to admit it. Best you get over it, because the
anger doesn't become you; Your posting rather makes you look like a fool
ATM.
Sorry.
Uli
Balog Pal
>I had an argument with some guy called Francis Glasssboro.
> He tried to wangle the term input to mean some bullshit it doesn't mean.
> He tried to misquote text from the standards to mean something it wasn't
> supposed to mean .
Aww, sure, is this still the issue passing 3 months?here:
http://www.phwinfo.com/forum/comp-lang-cplus/463378-input-cin.html
(note: news.virginmedia.com == paul as in OP)
<quote>
09/18/10, 10:55 #18
news.virginmedia.com
Re: input to cin
--------------------------------------------------------------------------------
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:N9GdnXZxLZIimAnR...@bt.com...
> On 18/09/2010 00:21, news.virginmedia.com wrote:
>>
>>
>> "Francesco S. Carta" <entu...@gmail.com> wrote in message
>> news:4c93dd94$0$6830$5fc...@news.tiscali.it...
>>> news.virginmedia.com <pchr...@yahoo.co.uk>, on 17/09/2010 20:34:24,
>>> wrote:
>>>
>>>>
>>>>
>>>> "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?
>>>
>>> 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 in order to clarify it.
>>>
>>> So, according to your view of the word "input", would you call "input"
>>> the action of transferring some data from std::cin to an object?
>>>
>>> --
>> I don't see how I can be any more clear about my view of input.
>> I will state my view once again if it makes it any clearer:
>>
>> With regards to the input streams which is the current context we're
>> referring to, we have:
>> source data -> stream -> object.
>> In this scenario I regard the input as the step data-> stream.
>>
>> The question you put forward is... would I call the next step of this
>> process input re:
>> stream -> object
>> This could be regarded as input to the object but if you call this input
>> is becomes confused with the main input process. It's much less
>> confusing to simply call this extraction or use some other word or
>> phrase.
>
> So that is a very long way of writing 'No' ? Correct me if I am mistaken.
>
> However note that the C++ Standard (which in context is what we are
> talking about) talks about input functions.
Is this is forum about the C++ standards? No.
So now YOU want to change the context to that of the standards?
You are also missing the big picture, that is you fail to acknowledge the
stream object.
As the >> operator is a member of the stream object I think It is
unreasonable to ignore it.
>A function is evaluated and in the case of operator >> the result is a
>pointer value which can, when necessary, be converted to a bool. I think it
>is not unreasonable to think that an input function does input, though in
>this case the input seems to be to a variable.
You , like Francesco, seem to be focusing ONLY on the extraction. You seem
to be trying to say that the main input process is extraction from the
stream to an object.
Ok lets say we are creating an input processing function, what is one of the
first things this function must to do?
Check for successful input.
Yes this function can be called an input function , or an input processing
function, but context of input here is input to the function because the
focus is the function.
If the focus is the stream the input is input to stream.
> I think the Standard is written that way because the 'input functions' are
> not required to get external input, it may be provided from within the
> program. Yes it might have been better to have called them extraction
> functions and if you feel strongly you can go to comp.std.C++ and raise a
> defect report. That is where such word games belong.
>
>
When people write standards their context is different as they are defining
a language, let me explain:
Suppose we a given a project to create a C++ stream library that reads and
write to a USB device.
But the C++ standards don't define USB devices, therefore its not a valid
C++ program? Of course this is wrong, it's is because the C++ standards are
in a different context.
You seem to be misinterpreting the purpose of the C++ standards as a
definition of the contextual interpretation of software engineering terms.
The C++ Standards is simply a guide that defines the expected behavior of
the language, it certainly doesn't define software engineering terms.
</quote>
Paul
"Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
news:80f8537a-86e3-4ad3...@m35g2000vbn.googlegroups.com...
Most of the argument was done by his freind Francesco ref:
http://groups.google.com/group/alt.comp.lang.learn.c-c++/browse_thread/thread/467be6f0e21c814f/d931599ea3db1ae2?q=clear+idea+about+input
Francis fully supported Francesco in his arguments with numerous postings
such as this one:
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/a70e0c43be410f2e
Paul
"Ulrich Eckhardt" <doom...@knuut.de> wrote in message
news:8o6bnq...@mid.uni-berlin.de...
Where did that come from?
No need to apologise for your post, really its ok. But I'm gonna ask you a
little question, feel free to answer if you like .........
How many standards apply to C++?
Paul
"Balog Pal" <pa...@lib.hu> wrote in message
news:ifl53a$248f$1...@news.ett.com.ua...
Yep apparently they're misinterpreting the standards.
Paul
"Michael Doubez" <michael...@free.fr> wrote in message
news:a0fa4a5c-a48a-4ea8...@w29g2000vba.googlegroups.com...
--
Michael
I see it's some kinda celebrity status here, programming skills not
required. I heard Victoria Beckham starteed programming she's very high up
in the programming community especially since she joined ACCU.
The only blind spot I acknowledge is the blindness to technical correctness.
Geoff
path at the edge of a stream they beheld a beautiful woman who was
afraid to cross the stream for fear of getting her beautiful clothes
wet from the water.
The eldest monk without a word simply picked her up and carried her
over the stream to the other side. The youngest one was shocked and
scandalized by such behavior from the elder monk but didn't say
anything about it.
After many days of walking and as they were about to reach the temple
the younger monk asked the elder about the incident, saying, "Do you
not think it was wrong to touch the beautiful woman and carry her
across the stream?"
The old man said, "I put her down at the side of the stream and never
gave her another thought. Have you been carrying her in your mind all
this time?"
Paul
"Geoff" <ge...@invalid.invalid> wrote in message
news:9d5th61i6uiida3cn...@4ax.com...
nice thought
I'd carry that one in my mind forever :)
happy new year.
Paul
"Geoff" <ge...@invalid.invalid> wrote in message
news:9d5th61i6uiida3cn...@4ax.com...
Ulrich Eckhardt
> But I'm gonna ask you a little question, feel free to answer if you
> like .........
>
> How many standards apply to C++?
I don't see the relevance here and I'm afraid this will wind down to a
nitpicking contest, so I'll decline your offer.
Uli
- off duty -
Paul
I don't intend to start a nitpicking contest and I am unsure myself , which
if why I asked. I only ask because some people refer to standards plural and
others singular. Someone once told me only the singular was correct, however
they provided no explanation of why standards must always be singular. I
think either can be used and as you said it seems like nitpicking :)
Ulrich Eckhardt
> "Ulrich Eckhardt" <doom...@knuut.de> wrote in message
> news:8o9j13...@mid.uni-berlin.de...
>> Paul wrote:
>>> But I'm gonna ask you a little question, feel free to answer if you
>>> like .........
>>>
>>> How many standards apply to C++?
>>
>> I don't see the relevance here and I'm afraid this will wind down to a
>> nitpicking contest, so I'll decline your offer.
> There is no need to be afraid of being incorrect as nobody knows
> everything.
I may be misinterpreting what you want to express here, but you seem to be
implying that I am afraid of being incorrect, which is not the case. The
thing I'm afraid of is that this discussion is mostly pointless and in
particular irrelevant to the initial topic of the thread.
> I don't intend to start a nitpicking contest and I am unsure
> myself , which if why I asked.
Again, you haven't said how this is relevant in a discussion about
behavior in discussions on the net, so I suggest that you start a new
thread on the topic. However, don't try asking questions in such a silly
way as you did here though. People here are not your pawns that answer
with yes/no on your order, as this has no value to them. Rather, try to
incite a fruitful discussion by explaining both sides of the problem as
you perceive them and then asking for other views of the issue.
Good luck!
Uli
Rui Maciel
> Hmm anger........^_^
> Where did that come from?
Your post does amount to nothing more than petty spite.
Rui Maciel
James Kanze
> On 12/31/2010 11:08 AM, Paul wrote:
> > When he is wrong but will not, and cannot, admit he is wrong, he can be
> > nothing more than a wanking idiot.
> This is a strong one, himself will come into play I suppose.
I doubt he'll waste his time. If this is the discussion I think
it is, Francis (and others) were simple expressing the consensus
of the C++ communitee (and most other experts).
--
James Kanze
Paul
"James Kanze" <james...@gmail.com> wrote in message
news:1a46ba9a-7557-4a2e...@m37g2000vbn.googlegroups.com...
miserably by displaying the spelling skills of a 5 year old and I doubt you
are in any position to speak on behalf of 'most experts'.
RaZiel
Is it you, Sheldon?
Francis Glassborow
I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual even
for native English speakers. In James' case he is writing in his third
language. How good is your French and German? You did not know? Well
that speaks volumes for James.
James is probably much better qualified to express an opinion as to the
positions of the majority of other C++ experts than are you. He knows
and is known by a great number of them and his opinions are generally
treated with respect even by those who disagree with him on some issue.
--
Note that robinton.demon.co.uk addresses are no longer valid.
Michael Doubez
> "Michael Doubez" <michael.dou...@free.fr> wrote in message
> >
> > news:a0fa4a5c-a48a-4ea8...@w29g2000vba.googlegroups.com...
> > On 31 d c, 11:08, "Paul" <pchris...@yahoo.co.uk> wrote:
> > > I had an argument with some guy called Francis Glasssboro.
> > Concerning Francis Glassborow, I know him only from his work at the
> > ACCU but what I have seen of him doesn't fit with what you describes.
> > He is also a former teacher and has written a book about C++ for
> > beginner (with good reviews) which speaks for him.
> >
> > Maybe you could reconsider the presence of a blind spot in your
> > reasonning.
>
>
> required. I heard Victoria Beckham starteed programming she's very high up
> in the programming community especially since she joined ACCU.
It is not a matter of celebrity but recognition of his involvement and
skills both within the ACCU and in the C++ community.
As for the threads about technical correctness you refers to, anybody
can read them and make up their own mind.
> The only blind spot I acknowledge is the blindness to technical correctness.
That may be part of the problem.
Let things cool off. Nobody cares about who is right or wrong, the
important is the result of the discussion: do you agree or not with
the technical outcome? If not, then it may be a good post for
comp.lang.c++.
--
Michael
Paul
You are deviating from the point, the point is that you and your friend
Francesco raised an argument about the relevant meaning of input. Your made
an attempt to misrepresent the standards, whether this was deliberate or if
you actually think you are correct, I don't know but these
misinterpretations were 100% incorrect. You fail to accept this fact yet
you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status, however
the quality of technical accuracy you display is very poor quality.
As an example I will quote some of the nonsense I have to deal with:
<snippet ref=
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/e43aa1f655aa7bc9?&q=clear+idea+about+input >
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.
</ snippet>
It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an object.
This is a complete misinterpretation of the standards as is your
interpretation of input.
It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an expert.
Blab on all you want about respecability in YOUR C++ community but who cares
about respectability in a community that excels only in poor quality. There
is nothing proffessional about misinterpreting the standards and making
technically incorrect statements on internet forums.
Leigh Johnston
A function is not part of an *object*; a function can be part of a
*class* though. A *class* is not an *object*.
/Leigh
Paul
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:ZcWdnTFAX-4uSbzQ...@giganews.com...
This guy actually thinks this is correct?
What good is any object without methods or functions? give yourself a shake
please.
Leigh Johnston
Of course I am correct. An object is an *instance* of a class; an
object is not a class. A class is a compile time artefact; an object is
a runtime artefact.
/Leigh
Michael Doubez
> "Francis Glassborow" <francis.glassbo...@btinternet.com> wrote in message
>
> news:evidnffQwpVoObzQ...@bt.com...
>
>
>
> > On 03/01/2011 01:31, Paul wrote:
>
> >>news:1a46ba9a-7557-4a2e...@m37g2000vbn.googlegroups.com...
> >>> On Dec 31 2010, 1:01 pm, Umut Tabak <umut.ta...@gmail.com> wrote:
> >>>> On 12/31/2010 11:08 AM, Paul wrote:
>
> >>>> > When he is wrong but will not, and cannot, admit he is wrong, he
> >>>> can be
> >>>> > nothing more than a wanking idiot.
>
> >>>> This is a strong one, himself will come into play I suppose.
>
> >>> I doubt he'll waste his time. If this is the discussion I think
> >>> it is, Francis (and others) were simple expressing the consensus
> >>> of the C++ communitee (and most other experts).
>
> >>> --
> >>> James Kanze
>
> >> You, who has made a petty attempt to appear intellectual, have failed
> >> miserably by displaying the spelling skills of a 5 year old and I doubt
> >> you are in any position to speak on behalf of 'most experts'.
>
> > I would guess that the spelling error is the result of being caught
> > between community and committee. Such errors are not that unusual even for
> > native English speakers. In James' case he is writing in his third
> > language. How good is your French and German? You did not know? Well that
> > speaks volumes for James.
>
> > James is probably much better qualified to express an opinion as to the
> > positions of the majority of other C++ experts than are you. He knows and
> > is known by a great number of them and his opinions are generally treated
> > with respect even by those who disagree with him on some issue.
>
>
> Francesco raised an argument about the relevant meaning of input. Your made
> an attempt to misrepresent the standards, whether this was deliberate or if
> you actually think you are correct, I don't know but these
> misinterpretations were 100% incorrect. You fail to accept this fact yet
> you seem to consider yourself a respected programmer.
> You and a few others here like to put yourselves across as respected
> programmers and label yourselves with some kind of expert status, however
> the quality of technical accuracy you display is very poor quality.
>
> As an example I will quote some of the nonsense I have to deal with:
>
> 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.
> </ snippet>
>
> It is complete nonsense to assume the standards or any other OOP
> documentation implies that functions are not an integral part of an object.
For a given definition of integral part.
- If you mean integral part as "a necessary part of an object" -
If members functions were integral part of an object, you could not
instantiate an object if a member function was not defined. In C++,
the compiler can be designed such that you can declare a member
function without defining it and the program would compile provided
the function definition is not needed.
- If you mean as "the function cannot be called outside an object"
Typically, static member functions are used as any other function and
have the same type as a free functions (ses [basic.compound]/note 45).
They are member functions (albeit static) and are not an integral part
of an object.
On some compilers, you can event call a member function on a NULL
pointer and it works provided you don't use any member. Well, it is UB
so you could argue that the result could have been anything but even
then, it shows something.
> This is a complete misinterpretation of the standards as is your
> interpretation of input.
You have not included this part and I am not sure about your argument
(and your quoting system makes it hard to read you). In the standard,
there are 2 concepts:
- std::streambuf which provides provides read/write functionalities
from character sequence in a physical devices (disk file, pipe ...).
- std::istream which provides reading and interpreting input from
sequences of characters (provided by a stream - see rdbuf() )
An input succeeds if the input sequence seen by std::istream could
generate an object of the wanted type. The std::streambuf is the one
to handle the eof() and physical input errors.
Typically, the last input before EOF in a file may succeed although
the streambuf encountered EOF to terminate the input. And it is only
the next input which will mark the stream input as failed.
> It is completely unbelievable that any person who agrees with these
> interpretations can consider themselves a programmer , never mind an expert.
Well, you cannot believe it. Which is a good thing: either you are
right and all will learn from you or you are wrong and as such on the
brink of discovering something.
> Blab on all you want about respecability in YOUR C++ community but who cares
> about respectability in a community that excels only in poor quality. There
> is nothing proffessional about misinterpreting the standards and making
> technically incorrect statements on internet forums.
I have not seen anybody trying to make you accept their authority but
going against a large group of professionals without strong arguments
should be a hint.
--
Michael
Leigh Johnston
More formally (in C++) an object is a region of storage, slightly less
formally an object is an instance of a *type* (which includes classes),
for example instances of built-in types are also objects:
int integerObject;
/Leigh
Paul
An object can and usually does contain functions or methods.
End of story mate there is no argument here.
Leigh Johnston
Wrong. An object does not "contain functions"; as far as C++ is
concerned an object is simply a region of storage. Perhaps this will
help your understanding:
A *function pointer* is an object.
A *function* is not an object.
I repeat: a *class* can contain functions, an *object* does not. An
object can be an *instance* of a class.
/Leigh
Paul
Its quite simple and clear what I mean, I will explain:
Objects can and, more often than not, do contain member functions. To
suggest that objects do not contain functions is complete nonsense.
My newsreader doesnt like to indent your text so sorry about that.
If members functions were integral part of an object, you could not
instantiate an object if a member function was not defined. In C++,
the compiler can be designed such that you can declare a member
function without defining it and the program would compile provided
the function definition is not needed.
- If you mean as "the function cannot be called outside an object"
Typically, static member functions are used as any other function and
have the same type as a free functions (ses [basic.compound]/note 45).
They are member functions (albeit static) and are not an integral part
of an object.
On some compilers, you can event call a member function on a NULL
pointer and it works provided you don't use any member. Well, it is UB
so you could argue that the result could have been anything but even
then, it shows something.
I don't know what you are blabbing on about here but you seem to be
generally trying to argue that objects do not contain functions. As I have
made clear I disagree with this and would go as far as to say its complete
and utter nonsense.
> This is a complete misinterpretation of the standards as is your
> interpretation of input.
You have not included this part and I am not sure about your argument
(and your quoting system makes it hard to read you). In the standard,
there are 2 concepts:
- std::streambuf which provides provides read/write functionalities
from character sequence in a physical devices (disk file, pipe ...).
- std::istream which provides reading and interpreting input from
sequences of characters (provided by a stream - see rdbuf() )
An input succeeds if the input sequence seen by std::istream could
generate an object of the wanted type. The std::streambuf is the one
to handle the eof() and physical input errors.
Typically, the last input before EOF in a file may succeed although
the streambuf encountered EOF to terminate the input. And it is only
the next input which will mark the stream input as failed.
I was referring to the general discussion where Francis and others argued
that, in the context of the standards, input meant to extract data from the
stream to a variable, I posted a link to this message earlier in this
discussion:
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/a70e0c43be410f2e.
This goes against logic and they are misinterpretting the standards.
> It is completely unbelievable that any person who agrees with these
> interpretations can consider themselves a programmer , never mind an
> expert.
Well, you cannot believe it. Which is a good thing: either you are
right and all will learn from you or you are wrong and as such on the
brink of discovering something.
If I am wrong then so must the overwhelming majority of texts on the
internet be wrong.
> Blab on all you want about respecability in YOUR C++ community but who
> cares
> about respectability in a community that excels only in poor quality.
> There
> is nothing proffessional about misinterpreting the standards and making
> technically incorrect statements on internet forums.
I have not seen anybody trying to make you accept their authority but
going against a large group of professionals without strong arguments
should be a hint.
--
Michael
So far all I've seen is a few people who state that objects don't have
functions. I have an overwhelming amount of internet links (all written by
proffessionals) that disagree with YOUR group of proffessionals.
Paul
You seem to be going around in cirlces and confusing yourself with classes
and instances of classes. Nobody mentioned classes or function definitions
or function pointers. or pointers to functions or pointers to function
pionters
The internal workings of a systems memory,CPU and how the function is stored
within an object is irrellevant. The point is that somehow that object
contains some kind of reference to the function and that function is an
integral part of the object.
As I said before an object can and usually does contain functions or
methods. This is not wrong and you have not given any evidence to support
that. The fact that you think an object cannot contain functions is wrong
however and if you want me to start posting links to prove that, I can do.
But I think it is best that you realise your error and waken up to the
facts.
And why do you feel the need to decorate your text with asterix?
Paul
"Michael Doubez" <michael...@free.fr> wrote in message
news:87ae969f-aa94-4e84...@m37g2000vbn.googlegroups.com...
test
Leigh Johnston
You are the one who is confused.
>
> The internal workings of a systems memory,CPU and how the function is
> stored within an object is irrellevant. The point is that somehow that
> object contains some kind of reference to the function and that function
> is an integral part of the object.
> As I said before an object can and usually does contain functions or
> methods. This is not wrong and you have not given any evidence to
> support that. The fact that you think an object cannot contain functions
> is wrong however and if you want me to start posting links to prove
> that, I can do. But I think it is best that you realise your error and
> waken up to the facts.
Your wrongness gets worse. Functions live in the text segment; objects
live in the data segment. If you instantiate 100 identical objects do
you think you will create 100 function "references" for each class
member function? Wrong. What about inlined inline member functions?
What about member functions which only have a declaration and no
definition? Try thinking.
The closest an object gets to storing function "references" is the
storage of a vtable pointer. You can have function pointer member
variables but this is not the same as "an object containing functions".
>
>
> And why do you feel the need to decorate your text with asterix?
Decent Usenet clients will displayed *text* in bold.
/Leigh
Keith Thompson
[...]
> Its quite simple and clear what I mean, I will explain:
> Objects can and, more often than not, do contain member functions. To
> suggest that objects do not contain functions is complete nonsense.
> My newsreader doesnt like to indent your text so sorry about that.
Your newsreader's failure to quote properly makes it difficult to
figure out who wrote what, so I'll just respond to this one paragraph.
You might want to investigate why your newsreader is malfunctioning,
and perhaps consider using a different one. You might also consider
trimming excessive quoted material.
Yes, what you mean is quite simple and clear. It's also quite wrong, at
least if you use the word "object" as it's defined by the C++ standard.
Quoting the 2003 version of the ISO C++ standard, section 1.8:
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.]
(The word "object" is in italics, indicating that this is the standard's
definition of the word. The second sentence does not directly refute
your claim; I include it for completeness.)
Member functions do not exist within objects. Member functions can
certainly be associated with objects, but they are not contained within
them.
It's possible, I suppose, to construct a consistent model of the C++
language in which member functions are contained within objects. But
doing so would probably require a non-standard meaning for "contained
within", or perhaps for "member function".
The syntax of C++ does tend to imply that member functions are
contained within objects the way member data is ("obj.func()"
vs. "obj.data"), but that's an abstraction, not a reflection of
what's actually going on.
Leigh Johnston also makes a good point. Suppose a class "C" defines a
member function "func", and suppose you have 10 objects of type C:
C arr[10];
If member functions are contained within objects, doesn't that imply
that there are 10 distinct member functions, one for each object C[0]
through C[9]?
If a member function is contained within an object, does the existence
of a member function contribute to the size of that object as reported
by sizeof? Why or why not?
--
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"
Ulrich Eckhardt
> As an example I will quote some of the nonsense I have to deal with:
>
> 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.
> </ snippet>
>
> It is complete nonsense to assume the standards or any other OOP
> documentation implies that functions are not an integral part of an
> object.
Why? The precise definition (if such a precise definition exists!) of an
object differs between languages, e.g. in some a type itself is an object,
in others it isn't. The C++ standard defines what "object" means in its
context, hence the title "The C++ object model". The C++ standard is
independent, it doesn't make any claims concerning the meaning of the term
"object" in different contexts and it isn't affected by the meaning of the
term "object" in different contexts either. The C++ standard is not
affected by other standards as it is unaffected by other OOP docs. To put
it differently, the C++ standard doesn't define what an object is, it only
defines what the term "object" means in the context of the C++ standard
itself.
BTW: C++ doesn't claim to be an OOP language, hence for example it doesn't
have methods but memberfunctions. So common OOP jargon can't be applied
unconditionally either.
> This is a complete misinterpretation of the standards as is your
> interpretation of input.
This may be a questionable use of the term object if you are an OOP
purist/zealot. Nonetheless, it is internally consistent and to me it makes
sense. I believe you could make sense of it if you wanted to, too.
> It is completely unbelievable that any person who agrees with these
> interpretations can consider themselves a programmer , never mind an
> expert.
>
> Blab on all you want about respecability in YOUR C++ community but who
> cares about respectability in a community that excels only in poor
> quality. There is nothing proffessional about misinterpreting the
> standards and making technically incorrect statements on internet
> forums.
Insulting people and calling names is professional and respectable
behaviour for an expert? Changing subject whenever an inconvenient
question would have to be answered? I'm not even talking about your
stylistic choices while structuring your postings, because that is
just my taste.
You leave me wondering what prompts your behaviour...
Uli
Paul
By your own words objects are created at runtime so how can it live in any
segment?
You try thinking about that and please dont suggest what I think and mark it
as wrong as if I had said it.
>
> The closest an object gets to storing function "references" is the storage
> of a vtable pointer. You can have function pointer member variables but
> this is not the same as "an object containing functions".
>
Who said an object STORES a function? It's only you who is saying that.
I said a member function is an integral part of an object. This is a
completely different concept from what you are saying.
As you seem to think that a function cannot be part of an object(or
instance) do you think all member functions are static?. Obviously they are
not, so wakey wakey.
Leigh Johnston
One can also consider the type of dispatch involved.
Calling an ordinary (non-inlined, non-virtual) class member function is
static dispatch; the address of the function is known at compile time so
storing this address in every object would be superfluous leading to
increased memory usage and presumably have the small overhead of
dereferencing the pointer when calling the function.
Calling a virtual class member function is dynamic dispatch; the address
of the function is not usually known at compile time which is why a
vtable pointer is stored in every object whose class contains one or
more virtual functions.
/Leigh
Leigh Johnston
>>>
>>> The internal workings of a systems memory,CPU and how the function is
>>> stored within an object is irrellevant. The point is that somehow that
>>> object contains some kind of reference to the function and that function
>>> is an integral part of the object.
>>> As I said before an object can and usually does contain functions or
>>> methods. This is not wrong and you have not given any evidence to
>>> support that. The fact that you think an object cannot contain functions
>>> is wrong however and if you want me to start posting links to prove
>>> that, I can do. But I think it is best that you realise your error and
>>> waken up to the facts.
>>
>> Your wrongness gets worse. Functions live in the text segment; objects
>> live in the data segment. If you instantiate 100 identical objects do
>> you think you will create 100 function "references" for each class
>> member function? Wrong. What about inlined inline member functions?
>> What about member functions which only have a declaration and no
>> definition? Try thinking.
>
> By your own words objects are created at runtime so how can it live in
> any segment?
Well static and heap objects live in the data segment, stack based
objects don't, however all of them are created at runtime.
> You try thinking about that and please dont suggest what I think and
> mark it as wrong as if I had said it.
You are wrong though.
>
>>
>> The closest an object gets to storing function "references" is the
>> storage of a vtable pointer. You can have function pointer member
>> variables but this is not the same as "an object containing functions".
>>
> Who said an object STORES a function? It's only you who is saying that.
> I said a member function is an integral part of an object. This is a
> completely different concept from what you are saying.
struct a { char c; };
struct b { char c; void f() {} };
You will find that sizeof(a) == sizeof(b); i.e. the function "f" (or any
reference to it) is not stored in any b objects, ergo a member function
is *not* an integral part of an object.
>
> As you seem to think that a function cannot be part of an object(or
> instance) do you think all member functions are static?. Obviously they
> are not, so wakey wakey.
>
I already said that an object can store a vtable pointer which is what
is used for dynamic dispatch; also this is a pointer to a table; there
are not multiple function references stored in an object which is what
you are asserting. Try reading what I wrote; you are the one who is asleep.
/Leigh
Leigh Johnston
If you disagree with what I said you asserted here is a reminder of what
you actually said:
"The point is that somehow that object contains some kind of reference
to the function and that function is an integral part of the object."
The only function references that are *indirectly* contained by objects
are the entries in a vtable a pointer to which will be contained by the
object if the class of which the object is an instance contains any
virtual functions. Any non-virtual class member functions will not have
an entry in any vtable; i.e. NO REFERENCE TO SUCH MEMBER FUNCTIONS EXIST
WITHIN AN OBJECT.
BTW you were not arguing about "virtual member functions"; you were
arguing about "member functions"; don't try and now pretend that you were.
/Leigh
Paul
"Keith Thompson" <ks...@mib.org> wrote in message
news:ln7helg...@nuthaus.mib.org...
> "Paul" <pchr...@yahoo.co.uk> writes:
> [...]
>> Its quite simple and clear what I mean, I will explain:
>> Objects can and, more often than not, do contain member functions. To
>> suggest that objects do not contain functions is complete nonsense.
>> My newsreader doesnt like to indent your text so sorry about that.
> [...]
>
> Your newsreader's failure to quote properly makes it difficult to
> figure out who wrote what, so I'll just respond to this one paragraph.
> You might want to investigate why your newsreader is malfunctioning,
> and perhaps consider using a different one. You might also consider
> trimming excessive quoted material.
>
> Yes, what you mean is quite simple and clear. It's also quite wrong, at
> least if you use the word "object" as it's defined by the C++ standard.
>
> Quoting the 2003 version of the ISO C++ standard, section 1.8:
>
> 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.]
>
> (The word "object" is in italics, indicating that this is the standard's
> definition of the word. The second sentence does not directly refute
> your claim; I include it for completeness.)
>
member functions?
All this says is that an object is a region of storage.
I can't understand why you think this says something other than that.
> Member functions do not exist within objects. Member functions can
> certainly be associated with objects, but they are not contained within
> them.
An object can contain a method function , yet the two entities can be stored
at different memory locations.
If you would prefer to say a member function was associated with an object
then thats fine , but I think it's more generally considered to be part of
the object.
>
> It's possible, I suppose, to construct a consistent model of the C++
> language in which member functions are contained within objects. But
> doing so would probably require a non-standard meaning for "contained
> within", or perhaps for "member function".
>
> The syntax of C++ does tend to imply that member functions are
> contained within objects the way member data is ("obj.func()"
> vs. "obj.data"), but that's an abstraction, not a reflection of
> what's actually going on.
Why do you think this is not a reflection of what is going on?
Member functions are a part of the object, they are in the objects scope and
have access to that objects members, the way these things are stored in
memory does not change this. You probably dont know where in memory that
object will be stored anyway and you will not be accessing its members using
pointer arithmetic or anything silly like that.
>
> Leigh Johnston also makes a good point. Suppose a class "C" defines a
> member function "func", and suppose you have 10 objects of type C:
>
> C arr[10];
>
> If member functions are contained within objects, doesn't that imply
> that there are 10 distinct member functions, one for each object C[0]
> through C[9]?
If you delve into the calling mechanics of specific systems you will
probably find that calls to a member function are passed and additional
argument which is a reference to their object. virtual functions and derived
classes and overriding functions get more complicated and have lookup tables
and stuff.
>
> If a member function is contained within an object, does the existence
> of a member function contribute to the size of that object as reported
> by sizeof? Why or why not?
>
> --
> 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"
>
Please do not confuse a member function being part of an object as meaning
the functions code is stored within the object in memory.
Leigh Johnston
> Please do not confuse a member function being part of an object as
> meaning the functions code is stored within the object in memory.
>
Stop repeatedly saying that others are confused when it is you who is
confused. Member functions (references or otherwise) are not "part of
an object"; vtables only apply to virtual member functions and are only
used for dynamic dispatch not static dispatch.
Maybe the problem is that you are unable to express yourself properly on
this medium.
/Leigh
Paul
"Ulrich Eckhardt" <doom...@knuut.de> wrote in message
news:8oeopa...@mid.uni-berlin.de...
see it like that at all.
It's a pretty simple concept and there are many texts on OOP if you find it
difficult to understand.
> BTW: C++ doesn't claim to be an OOP language, hence for example it doesn't
> have methods but memberfunctions. So common OOP jargon can't be applied
> unconditionally either.
>
According to Bjarne Stroustrup:
<quote>
"The reason for this is partly to introduce C++ and partly because C++ is
one of the few languages that supports both data abstraction and
objectoriented
programming in addition to
traditional programming techniques."
</quote>
<snip content="idiotic nonsense">
Paul
> On 03/01/2011 20:12, Paul wrote:
>>>>
>>>> The internal workings of a systems memory,CPU and how the function is
>>>> stored within an object is irrellevant. The point is that somehow that
>>>> object contains some kind of reference to the function and that
>>>> function
>>>> is an integral part of the object.
>>>> As I said before an object can and usually does contain functions or
>>>> methods. This is not wrong and you have not given any evidence to
>>>> support that. The fact that you think an object cannot contain
>>>> functions
>>>> is wrong however and if you want me to start posting links to prove
>>>> that, I can do. But I think it is best that you realise your error and
>>>> waken up to the facts.
>>>
>>> Your wrongness gets worse. Functions live in the text segment; objects
>>> live in the data segment. If you instantiate 100 identical objects do
>>> you think you will create 100 function "references" for each class
>>> member function? Wrong. What about inlined inline member functions?
>>> What about member functions which only have a declaration and no
>>> definition? Try thinking.
>>
>> By your own words objects are created at runtime so how can it live in
>> any segment?
>
> Well static and heap objects live in the data segment, stack based objects
> don't, however all of them are created at runtime.
>
that lives there is also created then.
>> You try thinking about that and please dont suggest what I think and
>> mark it as wrong as if I had said it.
>
> You are wrong though.
>
>>
>>>
>>> The closest an object gets to storing function "references" is the
>>> storage of a vtable pointer. You can have function pointer member
>>> variables but this is not the same as "an object containing functions".
>>>
>> Who said an object STORES a function? It's only you who is saying that.
>> I said a member function is an integral part of an object. This is a
>> completely different concept from what you are saying.
>
> struct a { char c; };
> struct b { char c; void f() {} };
>
> You will find that sizeof(a) == sizeof(b); i.e. the function "f" (or any
> reference to it) is not stored in any b objects, ergo a member function is
> *not* an integral part of an object.
>
>>
>> As you seem to think that a function cannot be part of an object(or
>> instance) do you think all member functions are static?. Obviously they
>> are not, so wakey wakey.
>>
>
> I already said that an object can store a vtable pointer which is what is
> used for dynamic dispatch; also this is a pointer to a table; there are
> not multiple function references stored in an object which is what you are
> asserting. Try reading what I wrote; you are the one who is asleep.
>
I am not saying that objects store multiple function references.
I didn't go into any details of calling mechanics because it only becomes an
issue if you are trying to argue about what is STORED within objects.
Is it impossible to understand that a member function can be part of an
object, yet that function is stored in a different area of memory?
Leigh Johnston
Segments are defined at compile/link time and created at runtime.
For the last time: a member function is part of a *class* not part of an
*object*.
This is a C++ newsgroup so the C++ Standard's definitions of "object"
and "member function" are de rigueur here in this newsgroup. An
"object" is a region of storage; not a region of storage plus a
collection of member functions.
/Leigh
Leigh Johnston
Perhaps this will help your understanding:
Non-static member functions *act* on objects; they are not part of objects.
/Leigh
Paul
> On 03/01/2011 20:28, Leigh Johnston wrote:
>> On 03/01/2011 20:12, Paul wrote:
>>>
>>> As you seem to think that a function cannot be part of an object(or
>>> instance) do you think all member functions are static?. Obviously they
>>> are not, so wakey wakey.
>>>
>>
>> I already said that an object can store a vtable pointer which is what
>> is used for dynamic dispatch; also this is a pointer to a table; there
>> are not multiple function references stored in an object which is what
>> you are asserting. Try reading what I wrote; you are the one who is
>> asleep.
>>
>
> If you disagree with what I said you asserted here is a reminder of what
> you actually said:
>
> "The point is that somehow that object contains some kind of reference to
> the function and that function is an integral part of the object."
>
attempt to go into details about the calling mechanics.
You are trying to argue that functions are not stored inside objects and I
was trying to get away from that scenario by introducing the concept that
functions and object can exist together yet in seperate areas of memory.
> The only function references that are *indirectly* contained by objects
> are the entries in a vtable a pointer to which will be contained by the
> object if the class of which the object is an instance contains any
> virtual functions. Any non-virtual class member functions will not have
> an entry in any vtable; i.e. NO REFERENCE TO SUCH MEMBER FUNCTIONS EXIST
> WITHIN AN OBJECT.
>
> BTW you were not arguing about "virtual member functions"; you were
> arguing about "member functions"; don't try and now pretend that you were.
>
I'm talking about all non static member functions I guess but Im not trying
to argue that they are actually stored within the objects memory as you try
to imply.
How difficult is it to understand the concept that the member function is
part of the object although they live in different places. There will be
some connection between function and object and the exact calling mechanics
are pretty irrellevant.
Keith Thompson
Yes, all it says is that an object is a region of storage. What makes
you think I think it says anything else?
It also says that functions to not necessarily occupy storage in the way
that objects do.
>> Member functions do not exist within objects. Member functions can
>> certainly be associated with objects, but they are not contained within
>> them.
>
> An object can contain a method function , yet the two entities can be
> stored at different memory locations.
> If you would prefer to say a member function was associated with an
> object then thats fine , but I think it's more generally considered to
> be part of the object.
Ok, I think I see the source of the confusion. You're using the word
"contain" and the phrase "part of" in a different sense than the rest of
us are.
Let me explain to you again how I (and I think, most other people)
understand the use of those terms.
An object is a region of storage. That's all it is. For something to
be *part of* an object (or, equivalently to be contained within an
object), it has to be somewhere within that region of storage.
Something outside the region of storage may well be associated with the
object, but it's not *part of* the object.
For example, a data member really is *part of* an object.
Can you at least understand that the sense in which a data member
is part of an object does not entirely apply to a member function?
[...]
> Please do not confuse a member function being part of an object as
> meaning the functions code is stored within the object in memory.
That's exactly what most of us thought you were trying to say, which is
why we've been telling you you're wrong.
Leigh Johnston
>
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:7ISdnZBUiPeXpb_Q...@giganews.com...
>> objects are the entries in a vtable a pointer to which will be
>> contained by the object if the class of which the object is an
>> instance contains any virtual functions. Any non-virtual class member
>> functions will not have an entry in any vtable; i.e. NO REFERENCE TO
>> SUCH MEMBER FUNCTIONS EXIST WITHIN AN OBJECT.
>>
>> BTW you were not arguing about "virtual member functions"; you were
>> arguing about "member functions"; don't try and now pretend that you
>> were.
>>
> I'm talking about all non static member functions I guess but Im not
> trying to argue that they are actually stored within the objects memory
> as you try to imply.
>
> How difficult is it to understand the concept that the member function
> is part of the object although they live in different places. There will
> be some connection between function and object and the exact calling
> mechanics are pretty irrellevant.
>
As I said else-thread:
Paul
When the member function is used by an object it is integral to that object
only.
>
> This is a C++ newsgroup so the C++ Standard's definitions of "object" and
> "member function" are de rigueur here in this newsgroup. An "object" is a
> region of storage; not a region of storage plus a collection of member
> functions.
>
> /Leigh
Correct the standards do not say that, an object is a region of storage plus
a collection of member functions, and neither did I.
Its pretty simple the member function lives in a diff place but it's still a
part of the object. It's a part of the object because it is within the
objects scope and it has accesss to the objects properties. The member
function also has access to the "this" keyword which is a pointer to the
object which that member function belongs.
Keith Thompson
[...]
> How difficult is it to understand the concept that the member function is
> part of the object although they live in different places. There will be
> some connection between function and object and the exact calling mechanics
> are pretty irrellevant.
It's not difficult at all to understand that concept, once you get
around to explaining that that's what you meant.
For most of this discussion, you've been asserting that member
functions are "part of" objects, *not* explaining what you meant,
and asserting that anyone who doesn't agree with your particular
use of terminology must be stupid.
Leigh Johnston
What do you mean by "integral to that object only"?
>>
>> This is a C++ newsgroup so the C++ Standard's definitions of "object"
>> and "member function" are de rigueur here in this newsgroup. An
>> "object" is a region of storage; not a region of storage plus a
>> collection of member functions.
>>
>> /Leigh
>
> Correct the standards do not say that, an object is a region of storage
> plus a collection of member functions, and neither did I.
> Its pretty simple the member function lives in a diff place but it's
> still a part of the object. It's a part of the object because it is
> within the objects scope and it has accesss to the objects properties.
> The member function also has access to the "this" keyword which is a
> pointer to the object which that member function belongs.
What do you mean by "objects scope"?
The member function is passed the "this" pointer when it is invoked and
that is the only connection between the object and the member function
and the connection is transient not permanent. As I said else-thread:
Paul
is specific to that object. The physical memory layout is irrellevant as are
the calling mechanics.
Another object of the same class may use the same function but in the second
instance the function does not have priveleges to the first object.
Paul
> "Paul" <pchr...@yahoo.co.uk> writes:
> [...]
>> How difficult is it to understand the concept that the member function is
>> part of the object although they live in different places. There will be
>> some connection between function and object and the exact calling
>> mechanics
>> are pretty irrellevant.
>
> It's not difficult at all to understand that concept, once you get
> around to explaining that that's what you meant.
>
> For most of this discussion, you've been asserting that member
> functions are "part of" objects, *not* explaining what you meant,
> and asserting that anyone who doesn't agree with your particular
> use of terminology must be stupid.
>
am sorry if I did.
Keith Thompson
That's a good start. Apology accepted.
Now I suggest you apologize to everyone else you've insulted in
this thread. Admitting the possibility that their point of view
might be as valid as yours would also be a nice gesture.
Please understand that, although I think I understand what you're
saying, I still disagree with you. I think your use of the terms
"contained in" and "part of" are inappropriate in the context of C++.
Paul
As I said below it has special priveleges to the object on which it was
called.
>
>>>
>>> This is a C++ newsgroup so the C++ Standard's definitions of "object"
>>> and "member function" are de rigueur here in this newsgroup. An
>>> "object" is a region of storage; not a region of storage plus a
>>> collection of member functions.
>>>
>>> /Leigh
>>
>> Correct the standards do not say that, an object is a region of storage
>> plus a collection of member functions, and neither did I.
>> Its pretty simple the member function lives in a diff place but it's
>> still a part of the object. It's a part of the object because it is
>> within the objects scope and it has accesss to the objects properties.
>> The member function also has access to the "this" keyword which is a
>> pointer to the object which that member function belongs.
>
> What do you mean by "objects scope"?
Not sure if scope is the correct term but what I mean is that a member
function is exclusively associated to the instance on which it has been
called.
It's OOP terms it's called an instance method.
Paul
As I said before I didn't realise I had insulted you, can you please point
out where I have insulted you and all the others you speak off?
And please dont point out the obvious insult toward FG, because there are
more ways to insult people than simply calling them a bad name and I believe
i was insulted first.
Their point of view isn't valid when it wrongly accuses my point of view of
being wrong, especially when they post snippets from the C++ standard and
blatantly misinterpret then. So I refuse to admit and point of view as valid
if it complete nonsense. And did you apologise to me for misinterpreting the
standards against my post to accuse me of being wrong? NO you did not. So
get off your moral high ground please.
>
> Please understand that, although I think I understand what you're
> saying, I still disagree with you. I think your use of the terms
> "contained in" and "part of" are inappropriate in the context of C++.
>
That's up to you, I dont recall saying "contained in" , although i did say
contains, which I agree is perhaps not the most suitable word. But 'part of'
is perfectly acceptable IMO.
Paul
Because you obviously used it as an argument to say that I was wrong.
>
> It also says that functions to not necessarily occupy storage in the way
> that objects do.
No it simply doesn't.
>
>>> Member functions do not exist within objects. Member functions can
>>> certainly be associated with objects, but they are not contained within
>>> them.
>>
>> An object can contain a method function , yet the two entities can be
>> stored at different memory locations.
>> If you would prefer to say a member function was associated with an
>> object then thats fine , but I think it's more generally considered to
>> be part of the object.
>
> Ok, I think I see the source of the confusion. You're using the word
> "contain" and the phrase "part of" in a different sense than the rest of
> us are.
The words mean what they mean.
>
> Let me explain to you again how I (and I think, most other people)
> understand the use of those terms.
>
> An object is a region of storage. That's all it is. For something to
> be *part of* an object (or, equivalently to be contained within an
> object), it has to be somewhere within that region of storage.
> Something outside the region of storage may well be associated with the
> object, but it's not *part of* the object.
>
Here you are trying to use terms as they are used in the context of the
standards.
In reality an object is more than simply a region of storage. It is very
narrow minded to think of an object in this way.
> For example, a data member really is *part of* an object.
>
> Can you at least understand that the sense in which a data member
> is part of an object does not entirely apply to a member function?
>
Its you that cant understand, if you continue to have this narrow minded
view of objects you will never understand much about it.
> [...]
>> Please do not confuse a member function being part of an object as
>> meaning the functions code is stored within the object in memory.
>
> That's exactly what most of us thought you were trying to say, which is
> why we've been telling you you're wrong.
>
Please can you list a few of the people you mean by "most of us" and lets
see if they agree with you. Because if you thought that a runtime object
shares the same memory space as a function definition you have a heck of a
lot to learn about programming mate.
I'm not so sure many people would like to step up and admit to that.
Paul
"Paul" <pchr...@yahoo.co.uk> wrote in message
news:jUtUo.21958$GJ7...@newsfe25.ams2...
> I'm not so sure many people would like to step up and admit to that.
>
*function code*
Keith Thompson
Yes, I did. Because, in my opinion, you *are* wrong. Does that
possibility never cross your mind?
>> It also says that functions to not necessarily occupy storage in the way
>> that objects do.
>
> No it simply doesn't.
Yes, it does.
A function is not an object, regardless of whether or not it
occupies storage in the way that objects do.
The "whether or not" implies at least the possibility that a function
might not occupy storage in the way that an object does.
>>
>>>> Member functions do not exist within objects. Member functions can
>>>> certainly be associated with objects, but they are not contained within
>>>> them.
>>>
>>> An object can contain a method function , yet the two entities can be
>>> stored at different memory locations.
>>> If you would prefer to say a member function was associated with an
>>> object then thats fine , but I think it's more generally considered to
>>> be part of the object.
>>
>> Ok, I think I see the source of the confusion. You're using the word
>> "contain" and the phrase "part of" in a different sense than the rest of
>> us are.
> The words mean what they mean.
Yes, they do. I wish I could help you to understand that.
>> Let me explain to you again how I (and I think, most other people)
>> understand the use of those terms.
>>
>> An object is a region of storage. That's all it is. For something to
>> be *part of* an object (or, equivalently to be contained within an
>> object), it has to be somewhere within that region of storage.
>> Something outside the region of storage may well be associated with the
>> object, but it's not *part of* the object.
>>
>
> Here you are trying to use terms as they are used in the context of
> the standards.
Yes, of course I am. These newsgroups discuss C++, which is defined by
the C++ standard. Using terms as the C++ standard defines them is
perfectly appropriate. Why do you think otherwise?
> In reality an object is more than simply a region of storage. It is
> very narrow minded to think of an object in this way.
It is the definition in the C++ standard. If you think it's a bad
definition, you're certainly entitled to your opinion, but I suggest
that you should at least acknowldge that it's a valid meaning
for the word "object" *in the context of C++*.
Note that a variable of type int is also an "object". The C++
standard uses the word "object" in a way that's not related to
object-oriented programming.
If you want to talk about OO-style "objects", I suggest that (a)
you define just what you mean by that, and (b) choose a different
term to avoid confusion.
>> For example, a data member really is *part of* an object.
>>
>> Can you at least understand that the sense in which a data member
>> is part of an object does not entirely apply to a member function?
>>
> Its you that cant understand, if you continue to have this narrow
> minded view of objects you will never understand much about it.
I repeat the above question: Can you at least understand that the sense
in which a data member is part of an object does not entirely apply to a
member function? So far the answer seems to be that you're incapable of
understanding that. By all means, prove me wrong.
>> [...]
>>> Please do not confuse a member function being part of an object as
>>> meaning the functions code is stored within the object in memory.
>>
>> That's exactly what most of us thought you were trying to say, which is
>> why we've been telling you you're wrong.
>>
> Please can you list a few of the people you mean by "most of us" and
> lets see if they agree with you. Because if you thought that a runtime
> object shares the same memory space as a function definition you have
> a heck of a lot to learn about programming mate.
> I'm not so sure many people would like to step up and admit to that.
No, nobody here believes that a function definition (or, as you
corrected in a followup, "function code") shares the same memory space
as an object of the class that defiens the function.
But your repeated claims that an object "contains" member functions,
along with the correct definition of a C++ object as "a region
of storage", led at least some of us to believe that you thought so.
Garrett Hartshaw
Hash: SHA1
>
>> [...]
>>> Please do not confuse a member function being part of an object as
>>> meaning the functions code is stored within the object in memory.
>>
>> That's exactly what most of us thought you were trying to say, which is
>> why we've been telling you you're wrong.
>>
> Please can you list a few of the people you mean by "most of us" and
> lets see if they agree with you. Because if you thought that a runtime
> object shares the same memory space as a function definition you have a
> heck of a lot to learn about programming mate.
> I'm not so sure many people would like to step up and admit to that.
>
I've tried to stay out of this, but I am one of those who agree with
him. And it's not that he thought that, it's that he (and I, although I
have not previously said so) thought that *you* thought that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNIpXEAAoJEO0SzzQOdchNWoUQAI3CnS8deHizqen3Huw3hx2z
/5UFww98H121kMagrpFWJ12c+Ps188IX/GSE+yxzNwoN8L+jRkwsQ7nvAUVTCCfh
a3eMLq7m2KVkJvTrpx5LnIgIw52DZfdO2wk3V6fIlRmji/Iu1/zYDrD467DvIzaB
J6VhfDW5t5wcaj4NpydZmdDkZXXR/YEA/vETxLm7upvSLlHwNIajtAgfbu9pDkwx
Hu0ToVJ1OWY8h7v2wK6dPPEFmhaDlHoQhwc8UKu8nE+VRT7FXPXnkW3Mkmr6mXFl
82PdTAglH895fXo1P25EfwO0Y8m0zwffSCopj2xBjR2N6NdDxJ/bVXbn4TINSL6S
XNA50HUFEdDPgErF9phpSLLT+eTdbahdF4rWPcGMHTu3sW28OyEY8m1L91mwPJ4A
TJP8oOO9LBhgi3XWVOM6hG5TNuiMAORDb+v6MsQ2oYUeWZJxTKbhR0ld5vY7eG5k
b+dSkob++h0cMoBv0N0TR6pk2MQxpBamJDF69dcAgNExKf2kBch2WS9NHdYOUmgQ
RpmvrMSsbdUkIQrB5sh6ekUSAadpdeUPJK9TAOnIsMiU6okGhvvUVRSBFyGXw1O1
7jctsnUyE0A2Ze53Z0VhQXSipxnp88dC11Xqv7MSGA1f6kLvkAPc+8TaIxb+MT+M
A1Vcg296ZCGjBMY0aIKs
=HmoI
-----END PGP SIGNATURE-----
Paul
imply the negative.
>>>
>>>>> Member functions do not exist within objects. Member functions can
>>>>> certainly be associated with objects, but they are not contained
>>>>> within
>>>>> them.
>>>>
>>>> An object can contain a method function , yet the two entities can be
>>>> stored at different memory locations.
>>>> If you would prefer to say a member function was associated with an
>>>> object then thats fine , but I think it's more generally considered to
>>>> be part of the object.
>>>
>>> Ok, I think I see the source of the confusion. You're using the word
>>> "contain" and the phrase "part of" in a different sense than the rest of
>>> us are.
>> The words mean what they mean.
>
> Yes, they do. I wish I could help you to understand that.
>
them?
>>> Let me explain to you again how I (and I think, most other people)
>>> understand the use of those terms.
>>>
>>> An object is a region of storage. That's all it is. For something to
>>> be *part of* an object (or, equivalently to be contained within an
>>> object), it has to be somewhere within that region of storage.
>>> Something outside the region of storage may well be associated with the
>>> object, but it's not *part of* the object.
>>>
>>
>> Here you are trying to use terms as they are used in the context of
>> the standards.
>
> Yes, of course I am. These newsgroups discuss C++, which is defined by
> the C++ standard. Using terms as the C++ standard defines them is
> perfectly appropriate. Why do you think otherwise?
>
Because the standards were written in a context, general programming
discussions are not carried out in the same context.
It doesn't make any difference anyway because the standards support my
argument.
>> In reality an object is more than simply a region of storage. It is
>> very narrow minded to think of an object in this way.
>
> It is the definition in the C++ standard. If you think it's a bad
> definition, you're certainly entitled to your opinion, but I suggest
> that you should at least acknowldge that it's a valid meaning
> for the word "object" *in the context of C++*.
No the standard defines an object as a region of storage, your
interpretation of this seems to be that an object is nothing more than a
region of storage.
>
> Note that a variable of type int is also an "object". The C++
> standard uses the word "object" in a way that's not related to
> object-oriented programming.
>
The word variable used almost 300 times in the C++ standard?
I don't think you understand the C++ object model at all.
> If you want to talk about OO-style "objects", I suggest that (a)
> you define just what you mean by that, and (b) choose a different
> term to avoid confusion.
>
No I will discuss Object Orientated programming as defined in the C++ Object
model.
>>> For example, a data member really is *part of* an object.
>>>
>>> Can you at least understand that the sense in which a data member
>>> is part of an object does not entirely apply to a member function?
>>>
>> Its you that cant understand, if you continue to have this narrow
>> minded view of objects you will never understand much about it.
>
> I repeat the above question: Can you at least understand that the sense
> in which a data member is part of an object does not entirely apply to a
> member function? So far the answer seems to be that you're incapable of
> understanding that. By all means, prove me wrong.
No I can't understand why you think this.
An object is not limited to the contents of the storage region it occupies..
>>> [...]
>>>> Please do not confuse a member function being part of an object as
>>>> meaning the functions code is stored within the object in memory.
>>>
>>> That's exactly what most of us thought you were trying to say, which is
>>> why we've been telling you you're wrong.
>>>
>> Please can you list a few of the people you mean by "most of us" and
>> lets see if they agree with you. Because if you thought that a runtime
>> object shares the same memory space as a function definition you have
>> a heck of a lot to learn about programming mate.
>> I'm not so sure many people would like to step up and admit to that.
>
> No, nobody here believes that a function definition (or, as you
> corrected in a followup, "function code") shares the same memory space
> as an object of the class that defiens the function.
So why have you argued that a member function is not a part of the object
because it's not contained within the objects storage region?
>
> But your repeated claims that an object "contains" member functions,
> along with the correct definition of a C++ object as "a region
> of storage", led at least some of us to believe that you thought so.
>
A member function is part of an object, this is a fact not a claim.
I quote your text:
<quote>
An object is a region of storage. That's all it is. For something to
be *part of* an object (or, equivalently to be contained within an
object), it has to be somewhere within that region of storage.
Something outside the region of storage may well be associated with the
object, but it's not *part of* the object.
For example, a data member really is *part of* an object.
</quote>
Your interpretation of the C++ standard is not only a very incorrect but
also seems very narrow minded, negative and bias.
The C++ Standard does not state what you say but it cleary states the exact
opposite.
<quote src="C++ Standard">
1.8 The C++ object model [intro.object]
2 Objects can contain other objects, called subobjects. A subobject can be a
member subobject (9.2)
</quote>
<quote src="C++ Standard">
9.2 Class members [class.mem]
1 The member-specification in a class definition declares the full set of
members of the class; no member
can be added elsewhere. Members of a class are data members, member
functions (9.3), nested types,
and enumerators. Data members and member functions are static or non-static;
see 9.4
And there is more.
</quote>
I think you have a very poor understanding of the words and terms used in
the C++ standards.
Good Luck!
Keith Thompson
>> "Paul" <pchr...@yahoo.co.uk> writes:
[...]
>>> The words mean what they mean.
>>
>> Yes, they do. I wish I could help you to understand that.
>>
> I use these words as defined in the english dictionary , how do you use
> them?
I use them as defined in the C++ standard. Why? Because both of
the newsgroups to which this discussion is posted are about C++,
and using the terminology defined by a language standard is the
best way to have a coherent conversation about the language.
[...]
> Because the standards were written in a context, general programming
> discussions are not carried out in the same context.
Then perhaps comp.programming or comp.object would be a better place
for this discussion.
> It doesn't make any difference anyway because the standards support my
> argument.
One minor point: there is one official C++ standard. There have been
multiple versions and drafts, and work is in progress on a new version
that will replace the current version. But it doesn't matter, since
I'm fairly sure all versions of the C++ standard define "object"
in the same way. And no, the standard doesn't support your argument.
>>> In reality an object is more than simply a region of storage. It is
>>> very narrow minded to think of an object in this way.
>>
>> It is the definition in the C++ standard. If you think it's a bad
>> definition, you're certainly entitled to your opinion, but I suggest
>> that you should at least acknowldge that it's a valid meaning
>> for the word "object" *in the context of C++*.
>
> No the standard defines an object as a region of storage, your
> interpretation of this seems to be that an object is nothing more than a
> region of storage.
Yes, of course. It's a *definition*.
If we define a triangle as a polygon with exactly three sides, then
under that definition a triangle is a polygon with exactly three sides
-- nothing more, nothing less. You can't say that a square is also a
triangle just because you feel like it; that would contradict the
definition.
Your claim that an object is more than just a region of storage
contradicts the C++ standard's definition of "object".
>> Note that a variable of type int is also an "object". The C++
>> standard uses the word "object" in a way that's not related to
>> object-oriented programming.
>>
> The word variable used almost 300 times in the C++ standard?
> I don't think you understand the C++ object model at all.
What does the number of times the standard uses the word "variable" have
to do with anything?
Given this declaration:
int x;
x is an object. Do you agree or disagree? (Hint: if you disagree,
you're wrong.)
>> If you want to talk about OO-style "objects", I suggest that (a)
>> you define just what you mean by that, and (b) choose a different
>> term to avoid confusion.
>>
>
> No I will discuss Object Orientated programming as defined in the C++ Object
> model.
I'm eagerly waiting for you to start doing so.
[big snip]
> I quote your text:
> <quote>
> An object is a region of storage. That's all it is. For something to
> be *part of* an object (or, equivalently to be contained within an
> object), it has to be somewhere within that region of storage.
> Something outside the region of storage may well be associated with the
> object, but it's not *part of* the object.
>
> For example, a data member really is *part of* an object.
> </quote>
Right.
> Your interpretation of the C++ standard is not only a very incorrect but
> also seems very narrow minded, negative and bias.
> The C++ Standard does not state what you say but it cleary states the exact
> opposite.
How so?
> <quote src="C++ Standard">
> 1.8 The C++ object model [intro.object]
> 2 Objects can contain other objects, called subobjects. A subobject can be a
> member subobject (9.2)
> </quote>
Right. That's entirely consistent with what I've been saying. Note
that a function is not a "member subobject". The standard could not
possibly be clearer in stating that a function is not an object.
> <quote src="C++ Standard">
> 9.2 Class members [class.mem]
> 1 The member-specification in a class definition declares the full set of
> members of the class; no member
> can be added elsewhere. Members of a class are data members, member
> functions (9.3), nested types,
> and enumerators. Data members and member functions are static or non-static;
> see 9.4
> And there is more.
> </quote>
Right. This is talking about members of a class, not parts of an object.
> I think you have a very poor understanding of the words and terms used in
> the C++ standards.
You are simultaneously arrogant and wrong. That's a dangerous
combination.
I give up.
Ulrich Eckhardt
> "Ulrich Eckhardt" <doom...@knuut.de> wrote in message
> news:8oeopa...@mid.uni-berlin.de...
>> Paul wrote:
>>> It is complete nonsense to assume the standards or any other OOP
>>> documentation implies that functions are not an integral part of an
>>> object.
>>
>> Why? The precise definition (if such a precise definition exists!) of
>> an object differs between languages, e.g. in some a type itself is an
>> object, in others it isn't. The C++ standard defines what "object"
>> means in its context, hence the title "The C++ object model". The C++
>> standard is independent, it doesn't make any claims concerning the
>> meaning of the term "object" in different contexts and it isn't
>> affected by the meaning of the term "object" in different contexts
>> either. The C++ standard is not affected by other standards as it is
>> unaffected by other OOP docs. To put it differently, the C++ standard
>> doesn't define what an object is, it only defines what the term
>> "object" means in the context of the C++ standard itself.
>>
> You make out its all very confusing and difficult and undefined but I
> don't see it like that at all.
No, it's very simple actually, and well-defined, too. You are confusing
the meaning of the term "object" from different contexts.
> It's a pretty simple concept and there
> are many texts on OOP if you find it difficult to understand.
The C++ standard defines the C++ object model. All your other texts on
general OOP may be interesting, but they are irrelevant to the C++
standard. They just don't apply. Get over it.
>> BTW: C++ doesn't claim to be an OOP language, hence for example it
>> doesn't have methods but memberfunctions. So common OOP jargon can't be
>> applied unconditionally either.
>>
> According to Bjarne Stroustrup:
> <quote>
> "The reason for this is partly to introduce C++ and partly because C++
> is one of the few languages that supports both data abstraction and
> objectoriented programming in addition to
> traditional programming techniques."
> </quote>
Being an OOP language is not the same as supporting OOP amongst other
programming techniques.
Ulrich Eckhardt
> The problem is you can't accept that the member function called on an
> object is specific to that object.
> Another object of the same class may use the same function but in the
> second instance the function does not have priveleges to the first
> object.
So first a member function is specific to an object but another object of
the same class may use the same function? That is a contradiction.
James Kanze
> On 3 jan, 14:20, "Paul" <pchris...@yahoo.co.uk> wrote:
> > "Francis Glassborow" <francis.glassbo...@btinternet.com> wrote in message
> >news:evidnffQwpVoObzQ...@bt.com...
[...]
> > As an example I will quote some of the nonsense I have to deal with:
> > <snippet ref=http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/e43aa1f6...>
> > 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.
> > </ snippet>
> > It is complete nonsense to assume the standards or any other OOP
> > documentation implies that functions are not an integral part of an object.
> For a given definition of integral part.
> - If you mean integral part as "a necessary part of an object" -
> If members functions were integral part of an object, you could not
> instantiate an object if a member function was not defined. In C++,
> the compiler can be designed such that you can declare a member
> function without defining it and the program would compile provided
> the function definition is not needed.
Just a nit, but it's not just that "the compiler can be designed
such that...". The standard if a function is not virtual, and
never called, the standard requires that the code compile and
link, even in the absense of a definition.
Using the vocabulary of the C++ standard, a function is clearly
not part of the object, but part of the class. Using another
vocabulary...? The word object is subject to so many different
definitions, I think it's probably best to stick to the one used
in the standard, at least when talking about C++. (More
generally, objects don't have members; classes do. Although it
does seem reasonable to speak of the member of an object *when*
each individual instance of the class has a distinct instance of
the member, e.g. data members and such compiler added things as
vptr.)
--
James Kanze
James Kanze
> On 03/01/2011 21:19, Paul wrote:
[...]
> Maybe the problem is that you are unable to express yourself properly on
> this medium.
Given the way he quotes, he clearly doesn't know how to use this
medium. Other than that, all I've seen is vague claims on his
part---and a declaration that's he's right, and that anyone who
disagrees with him is incompetent. But no facts to support his
position, whereas all of the people disagreeing with him are
quoting parts of the standard, or basing their statements on
work they've done on the standard, or with the standard
committee.
--
James Kanze
James Kanze
> "Paul" <pchris...@yahoo.co.uk> writes:
> > "Keith Thompson" <ks...@mib.org> wrote in message
> >news:lny671c...@nuthaus.mib.org...
> >> Yes, they do. I wish I could help you to understand that.
> > I use these words as defined in the english dictionary , how do you use
> > them?
> I use them as defined in the C++ standard. Why? Because both of
> the newsgroups to which this discussion is posted are about C++,
> and using the terminology defined by a language standard is the
> best way to have a coherent conversation about the language.
Also, no doubt, because general language dictionaries are not
necessarily good references when it comes to technical
vocabulary. Merriam Webster gives, as one definition of object,
"a data structure in object-oriented programming that can
contain functions as well as data, variables and other data
structures". This is *not* the way the C++ standard uses the
word, nor is it the way the Java specification uses it; in
general, I've never heard it used this way in a technical
discussion (but I'm not familiar with the vocabulary used in OO
languages without static typing, like Smalltalk).
--
James Kanze
Michael Doubez
Yes and it makes sense but I could not find a reference for it.
I was refering to 9.3/4 of the standard.
"There shall be at most one definition of a non-inline member function
in a program; no diagnostic is required."
[snip]
--
Michael
Francis Glassborow
But there it is: 'at most one' means that there might be none. There is
no other reasonable interpretation for that sentence.
BTW, on the issue of what is an object in C++; the C++ definition (and
note that in the context of C++ that definition supersedes any other
definition that might be found, that is the purpose of definitions
provided in Standards) is really akin to saying what the materials are
without saying how they are used. I think this is part of the problem
Paul is having.
In addition to the raw memory a variable (note that in the context of
C++ a variable would appear to be more than an object) has a type. It is
the type that has behaviour provided either directly by the Standard
(for fundamental types such as int and pointer to ) or my the member and
friend functions of a class.
Also note that the Standard refers to sub-objects when addressing the
issues of the part of an object that is assigned to a base class or data
member.
So, in C++ an object is a very primitive thing; just a region of memory.
Note that this region might not have an address (think of temporaries)
Yes, writing about C++ can lead to considerable confusion which is
exactly why we should try to use the terms in the way C++ has defined
them even if those terms might have other meanings in the broader
context of programming.
IMO Paul is often right in the broader context but does not seem to
grasp that that can make him mistaken in the narrower context of C++.
Paul
Are you stupid?
>
>> <quote src="C++ Standard">
>> 1.8 The C++ object model [intro.object]
>> 2 Objects can contain other objects, called subobjects. A subobject can
>> be a
>> member subobject (9.2)
>> </quote>
>
> Right. That's entirely consistent with what I've been saying. Note
> that a function is not a "member subobject". The standard could not
> possibly be clearer in stating that a function is not an object.
The standard defines subobject and member subobject in section 9.2, which is
why I quoted it.
The fact that the standard states that objects can contain subobjects is
the total opposite of what you said re:
"An object is a region of storage. That's all it is. "
>
>> <quote src="C++ Standard">
>> 9.2 Class members [class.mem]
>> 1 The member-specification in a class definition declares the full set of
>> members of the class; no member
>> can be added elsewhere. Members of a class are data members, member
>> functions (9.3), nested types,
>> and enumerators. Data members and member functions are static or
>> non-static;
>> see 9.4
>> And there is more.
>> </quote>
>
> Right. This is talking about members of a class, not parts of an object.
This is section 9.2, where member subobjects are defined.
A class is a template for an object, why do you speak as if they were two
completely different things?
>
>> I think you have a very poor understanding of the words and terms used in
>> the C++ standards.
>
> You are simultaneously arrogant and wrong. That's a dangerous
> combination.
>
> I give up.
>
I am not wrong, you are wrong.
Even with the evidence of the ++ standards laid out in front of you still
refuse to accept the truth.
Paul
"Garrett Hartshaw" <ghar...@gmail.com> wrote in message
news:ifu4k5$lc7$1...@speranza.aioe.org...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>>
>>> [...]
>>>> Please do not confuse a member function being part of an object as
>>>> meaning the functions code is stored within the object in memory.
>>>
>>> That's exactly what most of us thought you were trying to say, which is
>>> why we've been telling you you're wrong.
>>>
>> Please can you list a few of the people you mean by "most of us" and
>> lets see if they agree with you. Because if you thought that a runtime
>> object shares the same memory space as a function definition you have a
>> heck of a lot to learn about programming mate.
>> I'm not so sure many people would like to step up and admit to that.
>>
>
> I've tried to stay out of this, but I am one of those who agree with
> him. And it's not that he thought that, it's that he (and I, although I
> have not previously said so) thought that *you* thought tha
Do you agree with Keith who suggests that objects only contain whatever is
in their storage region?
If so you have alot to learn and are missing a grasp of the very basics.
Paul
Consider 2 instances of the same Object,
You could say that is a condradiction but you don't when you understand it.
Paul
"Francis Glassborow" <francis.g...@btinternet.com> wrote in message
news:2vCdnQ6x479Ekr7Q...@bt.com...
> On 04/01/2011 10:53, Michael Doubez wrote:
>> On 4 jan, 10:31, James Kanze<james.ka...@gmail.com> wrote:
>
>>> Just a nit, but it's not just that "the compiler can be designed
>>> such that...". The standard if a function is not virtual, and
>>> never called, the standard requires that the code compile and
>>> link, even in the absense of a definition.
>>
>> Yes and it makes sense but I could not find a reference for it.
>>
>> I was refering to 9.3/4 of the standard.
>> "There shall be at most one definition of a non-inline member function
>> in a program; no diagnostic is required."
>
> But there it is: 'at most one' means that there might be none. There is no
> other reasonable interpretation for that sentence.
>
> BTW, on the issue of what is an object in C++; the C++ definition (and
> note that in the context of C++ that definition supersedes any other
> definition that might be found, that is the purpose of definitions
> provided in Standards) is really akin to saying what the materials are
> without saying how they are used. I think this is part of the problem Paul
> is having.
I'm not having any problems.
>
> In addition to the raw memory a variable (note that in the context of C++
> a variable would appear to be more than an object) has a type. It is the
> type that has behaviour provided either directly by the Standard (for
> fundamental types such as int and pointer to ) or my the member and friend
> functions of a class.
>
> Also note that the Standard refers to sub-objects when addressing the
> issues of the part of an object that is assigned to a base class or data
> member.
Does the standard not also define member subobjects as it is written in
italics.
I think you will find it is section 9.2 , where member function is clearly
referred to as SUrprisingly enough a Memberrrrrrrr.
>
> So, in C++ an object is a very primitive thing; just a region of memory.
> Note that this region might not have an address (think of temporaries)
No it's not JUST a primative region of memory. THe standards themselves
stAte that an object can contain member subobjects
>
> Yes, writing about C++ can lead to considerable confusion which is exactly
> why we should try to use the terms in the way C++ has defined them even if
> those terms might have other meanings in the broader context of
> programming.
The problem is you misinterpret the standards as you have clearly done in
this post by stating:
" So, in C++ an object is a very primitive thing; just a region of memory."
This is commpletely different from what the standards state. In fact it is
almost the oppisite meaning.
>
> IMO Paul is often right in the broader context but does not seem to grasp
> that that can make him mistaken in the narrower context of C++.
>
If you think I'm incorrect please point out where.
I don't see how I can be incorrect when I am simply going with what is
stated in the standards.
Leigh Johnston
>
> If you think I'm incorrect please point out where.
> I don't see how I can be incorrect when I am simply going with what is
> stated in the standards.
>
>
Maybe this will help:
In some object oriented languages all member functions are effectively
"virtual" meaning that all objects in that language will contain
references to member functions via a table pointer or whatever (I have
even written an OO scripting language where this is the case); we are
talking about C++ however.
This is a C++ newsgroup.
In C++ an object is simply a "region of storage"; A sub-object is
simply a region of storage within a region of storage.
A member function is part of a class not part of an object.
A non-static member function *acts* on objects; it is not *part of* an
object.
/Leigh
Michael Doubez
> "Francis Glassborow" <francis.glassbo...@btinternet.com> wrote in message
>
> news:2vCdnQ6x479Ekr7Q...@bt.com...
>
>
>
> > On 04/01/2011 10:53, Michael Doubez wrote:
> >> On 4 jan, 10:31, James Kanze<james.ka...@gmail.com> wrote:
>
> >>> Just a nit, but it's not just that "the compiler can be designed
> >>> such that...". The standard if a function is not virtual, and
> >>> never called, the standard requires that the code compile and
> >>> link, even in the absense of a definition.
>
> >> Yes and it makes sense but I could not find a reference for it.
>
> >> I was refering to 9.3/4 of the standard.
> >> "There shall be at most one definition of a non-inline member function
> >> in a program; no diagnostic is required."
>
> > But there it is: 'at most one' means that there might be none. There is no
> > other reasonable interpretation for that sentence.
Ok. On first reading, I didn't catch that a compiler issuing an error
for undefined unused functions would not be standard compliant.
>
> > BTW, on the issue of what is an object in C++; the C++ definition (and
> > note that in the context of C++ that definition supersedes any other
> > definition that might be found, that is the purpose of definitions
> > provided in Standards) is really akin to saying what the materials are
> > without saying how they are used. I think this is part of the problem Paul
> > is having.
>
> I'm not having any problems.
>
>
>
> > In addition to the raw memory a variable (note that in the context of C++
> > a variable would appear to be more than an object) has a type. It is the
> > type that has behaviour provided either directly by the Standard (for
> > fundamental types such as int and pointer to ) or my the member and friend
> > functions of a class.
>
> > Also note that the Standard refers to sub-objects when addressing the
> > issues of the part of an object that is assigned to a base class or data
> > member.
>
> Does the standard not also define member subobjects as it is written in
> italics.
> I think you will find it is section 9.2 , where member function is clearly
> referred to as SUrprisingly enough a Memberrrrrrrr.
The exact title of 9.2 is "Class Members".
In fact, you could think of member functions as free functions with a
hidden parameter (this that inherit cv qualifiers of function) and
special access rights.
> > So, in C++ an object is a very primitive thing; just a region of memory.
> > Note that this region might not have an address (think of temporaries)
>
> No it's not JUST a primative region of memory. THe standards themselves
> stAte that an object can contain member subobjects
And ?
It is just a matter of memory layout, duration and order of
initialisation/destruction.
Typically, int he next standard, you will have standard-layout class
what are basically POD with member functions.
> > Yes, writing about C++ can lead to considerable confusion which is exactly
> > why we should try to use the terms in the way C++ has defined them even if
> > those terms might have other meanings in the broader context of
> > programming.
>
> The problem is you misinterpret the standards as you have clearly done in
> this post by stating:
> " So, in C++ an object is a very primitive thing; just a region of memory."
>
> This is commpletely different from what the standards state. In fact it is
> almost the oppisite meaning.
I will dutifuly quote the standard just has many have done.
"1.8 The C++ object model
The constructs in a C++ program create destroy, refer to, access, and
manipulate objects. And "object" is a region of storage. [Note: A
function is not an object, regardless of whether it occupies storage
in the way that objects do]. [...]
An object can have a name[...]has a storage duration[...]has a type.
[...]"
A function is not an object and as such cannot be a subobject.
In the last part, it is not said that an object can have a function
(only name,duration,type).
> > IMO Paul is often right in the broader context but does not seem to grasp
> > that that can make him mistaken in the narrower context of C++.
>
> If you think I'm incorrect please point out where.
> I don't see how I can be incorrect when I am simply going with what is
> stated in the standards.
I must have missed the relevant post in which you quote the standard
supporting your point.
--
Michael
Bart van Ingen Schenau
> "Ulrich Eckhardt" <dooms...@knuut.de> wrote in message
>
> news:8o9j13...@mid.uni-berlin.de...> Paul wrote:
> >> But I'm gonna ask you a little question, feel free to answer if you
> >> like .........
>
> >> How many standards apply to C++?
>
> > I don't see the relevance here and I'm afraid this will wind down to a
> > nitpicking contest, so I'll decline your offer.
>
> >http://xkcd.com/386/
>
> > Uli
> > - off duty -
>
> There is no need to be afraid of being incorrect as nobody knows everything.
> I don't intend to start a nitpicking contest and I am unsure myself , which
> if why I asked. I only ask because some people refer to standards plural and
> others singular. Someone once told me only the singular was correct, however
> they provided no explanation of why standards must always be singular. I
> think either can be used and as you said it seems like nitpicking :)
Ok, I will bite.
There is one official C++ standard document (ISO/IEC 14882:2003),
which contains normative references to four other standards. I have
not checked how many normative references these standards have.
So, there are at least 5 standards involved in defining the C++
language, of which the one designated as ISO/IEC 14882:2003 the most
important one is.
Bart v Ingen Schenau
red floyd
> And please dont point out the obvious insult toward FG, because there are
> more ways to insult people than simply calling them a bad name and I believe
> i was insulted first.
>
"But Mom, he did it first!" is usually not an acceptable excuse
anywhere.
Garrett Hartshaw
Hash: SHA1
And a region of storage (object) can be subdivided into smaller regions
of storage (subobject). Therefore, it is entirely consistent with what
he has said.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNI279AAoJEO0SzzQOdchNuSQP/R8YawoSA8B8IkkKrHLu55Ii
xYKbsJ3vc0/CMAbZlnMn+NtMz6Ulr8x7rbz05o7NxotqbnJaJ3IwsLG5lbW87AvC
exzqKxSvvfz1IovKzdfjML2bIyvhNSASCRGZJBlFfEUeDNlRB+IzsQXw+Rb3urGk
ukdLr3bm7hASkprPbqqzwZ6fum5HDqM3XTWtMNmkzD7VaocUGjejnTOf+pTcz+eR
U7S32mycze8vX4vDgiqkSU6igyES8rkOJi7Js1HXNJw3n/Apv4/twPh6uBhdP8dX
sGTBMbyvaLyndSMVZWnsK2rVgWfYWUuCxKohNc6IwRRYIXuDk5IjZgQY20QhUdv/
O1qYLtYWDRlA5O3OC6koVDoFFyvwDAslvjyC1nMBIl+8r1KXHVzgAwFqtCEc2saf
xP/Xq4C3hjnPNIBmGVY419iRasNYQPOxpBsSxVXnm75bdO2317JLVwLvkEk39561
BVo631Y2aQt3up8BLTbbSNrHD5Uz1i8+IlVFkKwY7omrjkTluimcJuvZHMRMqWF3
xTUK6MP6728HhWgQsmFWjphoJj1Bk5nPEH64vGfl3nBDeBfaMjhOxVYp9kZqQYM5
AJj3+cJYi35Kz2bJn5aSIE1hTKUVHO/krvSm6/07tnTuC9YSi07v270DiI6vocjl
pEhIGpAJZPRNFUBrdIhw
=ArcM
-----END PGP SIGNATURE-----
Garrett Hartshaw
Hash: SHA1
An object is an instance of a *class*. You cannot have 2 *instances* of
an object because you can't even have one.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJNI291AAoJEO0SzzQOdchNT6UP/3ort6hIcy29xz8xE15mB6iW
rtB6LRL22IUADJqfhGvEl9oP7nmWsg9UgYZ71SISwgSJtPK3+QMcG9XLpiYumZIv
//lNu+BCrznMi2Nkds4KJX6Y+d/vmkCWcCAfULfVU/QDeYJy7YqtF2a9Cr3Jfebj
FJ+BMVpufqFAH3ArPr5Wx1c0YFVuMm2av5kSXys6zJLJ0QMsjLnICqHofzEaLnpT
517N6NF9gOmaArt1fH6kIB7oYIFsimRpiyoOgqWnYiB2YojIGhFPW/PkGF9iNsB0
XTNr5GSjzIcevbdS47PA1QS/wA49E5KqC3g5V3kPgpdfIRiyER+rE+ReeBNtHFBa
shq4Yh/DryyIE8E3L4UW9AEmB5bqHfKKztXeyZ3rthjUQFcMA8+Tx9LqMzAUr6Az
9mwjeuYSOWxeWEXId5G0MoU3Zs93a58NmMs6iGjE2dzs4z3aFh5V+rFwBfwbKK24
xv4Gq8ZEkS5BOBqthBYOkEbGiH1iM8OzbAW+S7IhCYB1AsoUdWXIHNDFXl0VGsEK
z3jB6Ni9YUSdNTURYuYuFcJ/OP6p5cZG14DKabVOolgjbd71rhu9S6rXW6JlzloN
bulvXm0NAXDPfiilGCsnv0ibTOQvOesGqPF40pr4hn7mWIJ2DR8kQby3u5A/oG5c
DklHzvoN/MEVLis9ZLxZ
=BtI4
-----END PGP SIGNATURE-----
Paul
"Bart van Ingen Schenau" <ba...@ingen.ddns.info> wrote in message
news:7eec16e1-e023-4175...@p8g2000vbs.googlegroups.com...
Ok, I will bite.
Bart v Ingen Schenau
tyvm :)
Paul
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:QOWdnfJp-YS0rb7Q...@giganews.com...
> On 04/01/2011 14:00, Paul wrote:
>>
>> If you think I'm incorrect please point out where.
>> I don't see how I can be incorrect when I am simply going with what is
>> stated in the standards.
>>
>>
>
> Maybe this will help:
>
> In some object oriented languages all member functions are effectively
> "virtual" meaning that all objects in that language will contain
> references to member functions via a table pointer or whatever (I have
> even written an OO scripting language where this is the case); we are
> talking about C++ however.
>
describes member functions as being memebers of a C++ class, and therefore
an instanciated object of a C++ class can contain member subobjects. as
detailed in the C++ standards.
> This is a C++ newsgroup.
Correct.
>
> In C++ an object is simply a "region of storage"; A sub-object is simply
> a region of storage within a region of storage.
No an object is not SIMPLY a region of storage. A subobject does not
necessarilly reside within the same storage region as its respective
complete object.
>
> A member function is part of a class not part of an object.
A class is the definition for an object , you seem to think a class and an
object are not related.
If a member function is declared in a class then obviously it will be part
of the object insantiated from that class.
>
> A non-static member function *acts* on objects; it is not *part of* an
> object.
>
A non-static member function *can* act upon an object. A non-static member
function declared within an objects class is exclusivelly related to that
object and no other object.
You seem to think that member function is an independant entity that has no
connection to the object on which is called.
Previously you referred to text and data segments. I am unsure why you think
this format is the C++ standard. I repsect the fact that you are obviously
interested in this but I have have not encountered this type of program
since 16-bit asm. I am still curious when you refer to text and data
segments.
I believe obj files still use this this format however I haven't used any
elf libs recently. :)
Paul
"Michael Doubez" <michael...@free.fr> wrote in message
news:a8566e43-548c-4429...@d7g2000vbv.googlegroups.com...
--
Michael
...................................................................................................................................................
Well once again we seem to have a newsreader that doesn't like to indent
your txt.
However this will not stop me form replying to your post.
You have dutifu quoted form the standads a part of the following re:
<quote>
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. -end note ] An object is created by a definition (3.1),
by a new-expression (5.3.4) or
by the implementation (12.2) when needed. The properties of an object are
determined when the object is
created. An object can have a name (Clause 3). An object has a storage
duration (3.7) which influences
its lifetime (3.8). An object has a type (3.9). The term object type refers
to the type with which the object
is created. Some objects are polymorphic (10.3); the implementation
generates information associated with
each such object that makes it possible to determine that object's type
during program execution. For other
objects, the interpretation of the values found therein is determined by the
type of the expressions (Clause 5)
used to access them
</quote>
Please note that you have only quoted a small part of the standards and that
your interpretation of the standards is very incorrect.
If you were to read the next paragraph of the standards re~:
<quote>
2 Objects can contain other objects, called subobjects. A subobject can be a
member subobject (9.2), a base
class subobject (Clause 10), or an array element. An object that is not a
subobject of any other object is
called a complete object
</quote>
Now we see what the standards clearly states.
Please would you refrain form misinterpeting the C++ standards in this
newsgroup or any other newsgroup I chose to view as your misinterpretations
can be very confusing for someone less knowledgeable than myself. You have
chosen a small snippet of text from the standards and you have tried to
interpret it in such a way to mean something other than its intended
meaning. This suggests to me that you
a) do not understand the standards and the C++ programming language.
b) chose to misinterpret the standards to support an argument in which you
are fundamentally wrong.
Paul
Please note that this is outside the scope of the C++ standards, The C++
standard does not define the storage of runtime objects on any given system.
Paul
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/04/2011 08:46 AM, Paul wrote:
>>
>> "Ulrich Eckhardt" <doom...@knuut.de> wrote in message
>> news:8ofsnf...@mid.uni-berlin.de...
>>> Paul wrote:
>>>> The problem is you can't accept that the member function called on an
>>>> object is specific to that object.
>>> [...]
>>>> Another object of the same class may use the same function but in the
>>>> second instance the function does not have priveleges to the first
>>>> object.
>>>
>>> So first a member function is specific to an object but another object
>>> of
>>> the same class may use the same function? That is a contradiction.
>>>
>>
>> Consider 2 instances of the same Object,
>> You could say that is a condradiction but you don't when you understand
>> it.
>>
>
> An object is an instance of a *class*. You cannot have 2 *instances* of
> an object because you can't even have one.
object being a different entity.
If you cannot understand this please do not make obscure statemets that
imply the negative.
Paul
> On 03/01/2011 01:31, Paul wrote:
>>
>> "James Kanze" <james...@gmail.com> wrote in message
>> news:1a46ba9a-7557-4a2e...@m37g2000vbn.googlegroups.com...
>>> On Dec 31 2010, 1:01 pm, Umut Tabak <umut.ta...@gmail.com> wrote:
>>>> On 12/31/2010 11:08 AM, Paul wrote:
>>>
>>>> > When he is wrong but will not, and cannot, admit he is wrong, he
>>>> can be
>>>> > nothing more than a wanking idiot.
>>>
>>>> This is a strong one, himself will come into play I suppose.
>>>
>>> I doubt he'll waste his time. If this is the discussion I think
>>> it is, Francis (and others) were simple expressing the consensus
>>> of the C++ communitee (and most other experts).
>>>
>>> --
>>> James Kanze
>>>
>> You, who has made a petty attempt to appear intellectual, have failed
>> miserably by displaying the spelling skills of a 5 year old and I doubt
>> you are in any position to speak on behalf of 'most experts'.
>
> I would guess that the spelling error is the result of being caught
> between community and committee. Such errors are not that unusual even for
> native English speakers. In James' case he is writing in his third
> language. How good is your French and German? You did not know? Well that
> speaks volumes for James.
>
> James is probably much better qualified to express an opinion as to the
> positions of the majority of other C++ experts than are you. He knows and
> is known by a great number of them and his opinions are generally treated
> with respect even by those who disagree with him on some issue.
>
>
>
> --
> Note that robinton.demon.co.uk addresses are no longer valid.
>
Yes but its not the simple spelling error that is his downfall.
The fact that you proclaim him as a C++ expert is yet to be proven, if he
believes that an object does does not contain member functions he is not
worthy of being a programmer , never mind a C++ expert...
If you cannot accept that the C++ programming language uses objects which
contain member functions then you have problem. If you think the C++
programming language defines 'input' to mean extraction you have a problem.
If you refuse to be corrected by someone as trivial as me then you have a
problem. Because I won't back down to incorrectness when I know I'm right.
Öö Tiib
> "Garrett Hartshaw" <gharts...@gmail.com> wrote in message
>
> > And a region of storage (object) can be subdivided into smaller regions
> > of storage (subobject). Therefore, it is entirely consistent with what
> > he has said.
>
> Can you please elaborate on what you mean by this?
> Please note that this is outside the scope of the C++ standards, The C++
> standard does not define the storage of runtime objects on any given system.
Any given system does not matter, nature and contents of storage of
object are described by type of object in C++. There are languages
where you can alter objects run-time and add new member functions and
new data members to objects (like Javascript). In such languages
members, their existence and nature are described by object. Such
languages are better to discuss elsewhere, because C++ does not have
such capabilities.
We discuss C++ here and so we use C++ object model where member
functions and data members are described by and belong to class and
are not objects or parts of objects. Types are not objects in C++,
functions and member functions are not objects in C++.
Objects whose type is a class are merely instances of that class. Data
members of class describe subobjects of each instance. Such subobjects
are contained in the region of storage of object and are part of that
object. Types can not be modified run-time by C++ program, functions
can not be modified by C++ program. Once object is instantiated it has
a type and can be used in (related to that type) functions. If you
need to achieve something more dynamic than that then you have to use
pointers to other objects (or member objects) or pointers to functions
(or member functions).
Michael Doubez
> "Michael Doubez" <michael.dou...@free.fr> wrote in message
>
> news:a8566e43-548c-4429...@d7g2000vbv.googlegroups.com...
> On 4 jan, 15:00, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>
>
> > "Francis Glassborow" <francis.glassbo...@btinternet.com> wrote in message
[snip]
...................................................................................................................................................
> Well once again we seem to have a newsreader that doesn't like to indent
> your txt.
You seem the only one to have this problem.
> However this will not stop me form replying to your post.
>
> You have dutifu quoted form the standads a part of the following re:
> <quote>
[snip]
> [ Note: A function is not an object, regardless of
> whether or not it occupies storage in the
> way that objects do. -end note ]
From the quote you copy paste, you see that functions are not object.
Right ?
[snip]
>
> Please note that you have only quoted a small part of the standards and that
I quoted only the relevant part in order to keep it short (and I have
here only my compagny's old C++98 standard pdf which doesn't allow
copy/paste). And while you quote the full text, don't give your
interpretation.
> your interpretation of the standards is very incorrect.
Really ? Please elaborate ... after all don't.
> If you were to read the next paragraph of the standards re~:
> <quote>
> 2 Objects can contain other objects, called subobjects. A subobject can be a
> member subobject (9.2), a base
> class subobject (Clause 10), or an array element. An object that is not a
> subobject of any other object is
> called a complete object
> </quote>
Which is basically a way to see that the memory area of an object is
an agregation of the memory areas of its suboject. Not great news, it
is already the same for struct in C (except for base class).
And we have seen from your quote that functions are not objects and
thus are not part of an object.
> Now we see what the standards clearly states.
> Please would you refrain form misinterpeting the C++ standards in this
> newsgroup or any other newsgroup I chose to view as your misinterpretations
> can be very confusing for someone less knowledgeable than myself. You have
> chosen a small snippet of text from the standards and you have tried to
> interpret it in such a way to mean something other than its intended
> meaning. This suggests to me that you
> a) do not understand the standards and the C++ programming language.
> b) chose to misinterpret the standards to support an argument in which you
> are fundamentally wrong.
So you are basically telling me that I am incompetent and dishonest.
From you it is a compliment since you said as much to active members
of WG21.
Really, I don't see the point in continuing this thread.
"The Haughty do but build castle walls behind which they seek to hide
their doubts and fears." - Bene Gesserit Axiom
--
Michael
Francis Glassborow
> Yes but its not the simple spelling error that is his downfall.
> The fact that you proclaim him as a C++ expert is yet to be proven, if
> he believes that an object does does not contain member functions he is
> not worthy of being a programmer , never mind a C++ expert...
Exactly what are your credentials to claim to be an expert (the often
lecturing tone of many of your posts clearly show that in your own mind
you are an expert). Your continued ignorance of who you are talking
about reveals that you actually have very little knowledge as to who
have credentials as C++ experts (though few of those who are would be
arrogant enough to claim that they were)
I do not claim to be an expert though my credentials include
representing my country at ISO meetings for both C and C++ over almost
two decades and frequently being designated by my country's Standards
body (BSI) as being the Principle UK Expert at those meetings.
Nonetheless I do not consider myself an expert just someone who had the
time and the inclination to attempt to contribute constructively to the
development of C++.
>
> If you cannot accept that the C++ programming language uses objects
> which contain member functions then you have problem. If you think the
> C++ programming language defines 'input' to mean extraction you have a
> problem.
As usual you trivialise by ignoring the wider context.
> If you refuse to be corrected by someone as trivial as me then you have
> a problem. Because I won't back down to incorrectness when I know I'm
> right.
Yes and I guess it is only the current season that has encouraged so
many others to attempt to persuade you to understand more than you do.
Does it not seem strange to you that not a single person here (in
a.c.l.c-c++) has supported your views? At least half of the contributors
to this thread are highly respected and widely acknowledged experts.
If anyone thinks I am being unfair to you I hope they will now post
their disagreement with me. That you will disagree is a foregone
conclusion so do not waste your time by replying.
Joshua Maurice
> A subobject does not
> necessarilly reside within the same storage region as its respective
> complete object.
While this might be correct with a most broad reading of the standard,
it cannot be on any sane implementation. Simple placement-new usage
makes such an implementation impossible or perverse (perverse w.r.t.
the spirit and intent of C++ and its design goals). All sub-objects on
all non-perverse implementations exist in the memory region of the
complete object.
To add nothing to this otherwise useless conversation of this thread:
This entire argument is one over the definition of the term "a part
of". Let me take a stab at it. Consider the following:
class Foo { void bar(){} };
Foo x;
In the common, standard, etc., abstraction and terminology of C++ and
statically typed programming languages - it's quite silly to say that
Foo::bar is a part of x. This is an argument over definition, and thus
I have only two options - appeal to authority, or appeal to consensus.
Either way, for any reputable authority and any relevant consensus, I
win.
In short, "a part of" implies some sort of containment or ownership
relation. A class does "contain and "own" its member functions - a
member function is contained by exactly one class, and it makes sense
only in the context of that class. An object does not "contain" nor
"own" its type, and an object does not "contain" nor "own" its
associated member functions - there often are multiple objects of a
specific type or a specific member function. Thus member functions are
not part of objects, in the common lingo.
Leigh Johnston
>
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:QOWdnfJp-YS0rb7Q...@giganews.com...
>> On 04/01/2011 14:00, Paul wrote:
>>>
>>> If you think I'm incorrect please point out where.
>>> I don't see how I can be incorrect when I am simply going with what is
>>> stated in the standards.
>>>
>>>
>>
>> Maybe this will help:
>>
>> In some object oriented languages all member functions are effectively
>> "virtual" meaning that all objects in that language will contain
>> references to member functions via a table pointer or whatever (I have
>> even written an OO scripting language where this is the case); we are
>> talking about C++ however.
>>
> The C++ object model is described in the C++ Standards. The C++ standard
> describes member functions as being memebers of a C++ class, and
> therefore an instanciated object of a C++ class can contain member
> subobjects. as detailed in the C++ standards.
An object can contain sub-objects yes; member functions are not sub-objects.
>
>> This is a C++ newsgroup.
>
>
> Correct.
>>
>> In C++ an object is simply a "region of storage"; A sub-object is
>> simply a region of storage within a region of storage.
>
> No an object is not SIMPLY a region of storage. A subobject does not
> necessarilly reside within the same storage region as its respective
> complete object.
According to the C++ Standard an object *is* simply a region of storage.
A sub-object is a region of storage within a region of storage.
>>
>> A member function is part of a class not part of an object.
>
> A class is the definition for an object , you seem to think a class and
> an object are not related.
> If a member function is declared in a class then obviously it will be
> part of the object insantiated from that class.
>
>>
>> A non-static member function *acts* on objects; it is not *part of* an
>> object.
>>
> A non-static member function *can* act upon an object. A non-static
> member function declared within an objects class is exclusivelly related
> to that object and no other object.
The only connection between a member function and an object is
transient, only existing when the member function is invoked and passed
a "this" pointer. Member functions are explicitly related to classes
not objects; as objects are "related" to classes one can obviously say
that objects are "related" to member functions but this is woolly and
technically inaccurate.
>
> You seem to think that member function is an independant entity that has
> no connection to the object on which is called.
The only connection is the passed "this" pointer during invocation
otherwise objects are completely independent to member functions. A
member function is *part of* a class; a member function is *not part of*
an object. After compilation classes cease to exist and member
functions are turned into a series of machine code instructions
alongside normal functions and live in the text segment totally
independent to any objects that are later created at runtime. Objects
can have vtable pointers but that doesn't translate to "member functions
are *part of* an object".
>
>
> Previously you referred to text and data segments. I am unsure why you
> think this format is the C++ standard. I repsect the fact that you are
> obviously interested in this but I have have not encountered this type
> of program since 16-bit asm. I am still curious when you refer to text
> and data segments.
> I believe obj files still use this this format however I haven't used
> any elf libs recently. :)
I used segments to illustrate that member functions are completely
separate to objects.
You seem to think that *you* are correct and *everybody else* in this
thread is wrong. How many more people will it take to convince you that
you are wrong?
Can you cite anything from the C++ standard that backs up your claim
that member functions are part of objects? Remember this is a C++
newsgroup within which the term "object" is not the same as the term
"object" used in object oriented programming.
/Leigh
Francis Glassborow
> On Jan 4, 7:17 pm, "Paul"<pchris...@yahoo.co.uk> wrote:
>> A subobject does not
>> necessarilly reside within the same storage region as its respective
>> complete object.
>
> While this might be correct with a most broad reading of the standard,
> it cannot be on any sane implementation. Simple placement-new usage
> makes such an implementation impossible or perverse (perverse w.r.t.
> the spirit and intent of C++ and its design goals). All sub-objects on
> all non-perverse implementations exist in the memory region of the
> complete object.
No it simply cannot be done. All subobjects must reside in a single
contiguous region which is the object. Otherwise sizeof and operator new
would be useless:
Assuming Mytype has been defined:
then operator new(sizeof(Mytype)) is required to provide sufficient
contiguous storage for an instance of Mytype.
And the same restriction applies to malloc etc.
There is simply no way, perverse or otherwise, that a complete object
does not occupy a single contiguous block of storage.
Francis
Leigh Johnston
>
> think this format is the C++ standard. I repsect the fact that you are
> obviously interested in this but I have have not encountered this type
> of program since 16-bit asm. I am still curious when you refer to text
> and data segments.
> I believe obj files still use this this format however I haven't used
> any elf libs recently. :)
Don't confuse Intel segment registers with "program segments"; they are
not the same thing.
/Leigh
Keith H Duggar
<francis.glassbo...@btinternet.com> wrote:
> If anyone thinks I am being unfair to you I hope they will now post
> their disagreement with me. That you will disagree is a foregone
> conclusion so do not waste your time by replying.
What can be said has been said in many ways many times. At this
point the OP is acting like a troll. For trolls it best to just
call bs and then ignore. Any extra attention simply fuels their
trolling.
KHD
James Kanze
> On 4 jan, 10:31, James Kanze <james.ka...@gmail.com> wrote:
> > > On 3 jan, 14:20, "Paul" <pchris...@yahoo.co.uk> wrote:
> > > > "Francis Glassborow" <francis.glassbo...@btinternet.com> wrote in message
> > > >news:evidnffQwpVoObzQ...@bt.com...
> > [...]
> > > > As an example I will quote some of the nonsense I have to deal with:
> > > > <snippet ref=http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/e43aa1f6...>
> > > > 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.
> > > > </ snippet>
> > > > It is complete nonsense to assume the standards or any other OOP
> > > > documentation implies that functions are not an integral part of an object.
> > > For a given definition of integral part.
> > > - If you mean integral part as "a necessary part of an object" -
> > > If members functions were integral part of an object, you could not
> > > instantiate an object if a member function was not defined. In C++,
> > > the compiler can be designed such that you can declare a member
> > > function without defining it and the program would compile provided
> > > the function definition is not needed.
> > Just a nit, but it's not just that "the compiler can be designed
> > such that...". The standard if a function is not virtual, and
> > never called, the standard requires that the code compile and
> > link, even in the absense of a definition.
> Yes and it makes sense but I could not find a reference for it.
> I was refering to 9.3/4 of the standard.
> "There shall be at most one definition of a non-inline member function
> in a program; no diagnostic is required."
It's in §3.2/3: "Every program shall contain exactly one
definition of every non-inline function or object that is used
in that program." The preceding paragraph contains the
definition of what it means to be used, in particular "An object
or non-overloaded function is used if its name appears in
a potentially-evaluated expression. A virtual member function is
used if it is not pure."
In sum, unless the function is actually used, there is no
requirement to provide a definition (but "used" is automatic if
the function is virtual, even if it is never called). Other
texts specify that there can never be more than one definition
(unless the function is inline or a template).
--
James Kanze
James Kanze
> Maybe this will help:
More to the point, C++ very distinctly distinguishes between
"object" and "class", with an object being an instance of
a class. Formally, it is the class which has members, not the
object, although it makes sense in less formal speech to speak
of the members of an object when one is referring to the members
of the class which have a separate instance in each object (e.g.
the non-static data members).
--
James Kanze
James Kanze
> On 05/01/2011 03:17, Paul wrote:
[...]
> You seem to think that *you* are correct and *everybody else* in this
> thread is wrong. How many more people will it take to convince you that
> you are wrong?
Note that the issue in this discussion is one of vocabulary.
This is not a technical issue, and in a real sense, since all
meanings are arbitrary, there is no technical answer, and the
question can't be addressed by technical arguments. Unlike
technical questions, invocation of authority *is* an argument;
in the end, you can define a word any way you please, but if you
want to communicate successfully, you have to use a definition
which is the same as that of other people; in technical fields,
this definition is generally established by consensus of the
experts.
Neither Francis nor Paul can present technical arguments for
something that is not a technical question. The fact that
Francis is an acknowledged expert, and regularly communicates
with other acknowledged experts, however, lends authority to his
statements: he can report (and is reporting) the consensus among
such experts. To date, Paul has yet to show any indication that
anyone else, expert or not, agrees with and uses his
definitions. Which doesn't make them wrong. Just useless, if
your goal is to communicate.
--
James Kanze
Paul
"Joshua Maurice" <joshua...@gmail.com> wrote in message
news:8498f485-bd27-4660...@z19g2000yqb.googlegroups.com...
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
If a child is PART OF a sunday school group there is no containment or
ownership.
To be PART OF a group does not imply containment or ownership as you seem to
think. Your definintion of "PART OF" is very wrong as would your definition
of anything else probably be.
Paul
> On 05/01/2011 11:51, Joshua Maurice wrote:
>> On Jan 4, 7:17 pm, "Paul"<pchris...@yahoo.co.uk> wrote:
>>> A subobject does not
>>> necessarilly reside within the same storage region as its respective
>>> complete object.
>>
>> While this might be correct with a most broad reading of the standard,
>> it cannot be on any sane implementation. Simple placement-new usage
>> makes such an implementation impossible or perverse (perverse w.r.t.
>> the spirit and intent of C++ and its design goals). All sub-objects on
>> all non-perverse implementations exist in the memory region of the
>> complete object.
>
> No it simply cannot be done. All subobjects must reside in a single
> contiguous region which is the object. Otherwise sizeof and operator new
> would be useless:
When an object is instantiated at runtime, whether it be on the heap or on
the stack, it cannot possibly share the same memory address as the code
which defines that object.
To suggest this is ridiculous.
> Assuming Mytype has been defined:
>
> then operator new(sizeof(Mytype)) is required to provide sufficient
> contiguous storage for an instance of Mytype.
>
An objects type is defined by its class definition.
> And the same restriction applies to malloc etc.
>
> There is simply no way, perverse or otherwise, that a complete object does
> not occupy a single contiguous block of storage.
>
> Francis
If an object containing 99 pointers is allocated 99 different memory
addresses, do these memory adressses need to be withing the the same area of
memory as the code that is the objects class definition?
This is a nonsensical suggestion.
A 'member subobject' and a subobject are 2 completely different things. An
object CAN contain a member subobject as defined in the standards. If you
chose to ignore this how can your idea of a complete object be accepted?
Keith Thompson
[...]
> We discuss C++ here and so we use C++ object model where member
> functions and data members are described by and belong to class and
> are not objects or parts of objects. Types are not objects in C++,
> functions and member functions are not objects in C++.
I think you misspoke here. Data members are parts of objects.
--
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"