«

"Leigh Johnston" <> wrote in message
news: ...
> On 03/01/2011 22:49, Paul wrote:
>>
>> "Leigh Johnston" <> wrote in message
>> news: ...
>>> On 03/01/2011 22:12, Paul wrote:
>>>>
>>>> "Leigh Johnston" <> wrote in message
>>>> news:T-KdncI4JujGrL_QnZ2dnUVZ8q-...
>>>>> 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.
>>>>>
>>>> a data segment is created at compile time or link time, so surely
>>>> anything that lives there is also created then.
>>>
>>> Segments are defined at compile/link time and 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.
>>>>>
>>>> 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?
>>>
>>> For the last time: a member function is part of a *class* not part of
>>> an *object*.
>> A function definition is a member of a class or a static member function.
>> When the member function is used by an object it is integral to that
>> object only.
>
> What do you mean by "integral to that object only"?

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.

> 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:
>
> "Non-static member functions *act* on objects; they are not part of
> objects."
>
> /Leigh

"Keith Thompson" <kst-> wrote in message
news:...
> "Paul" <> writes:
>> "Keith Thompson" <kst-> wrote in message
>> news:...
>>> "Paul" <> 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.
>>>
>> I'm glad you understand and I have not intended to assert you as stupid ,
>> I
>> am sorry if I did.
>
> 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.

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.

"Keith Thompson" <kst-> wrote in message
news:...
> "Paul" <> writes:
>> "Keith Thompson" <kst-> wrote in message
>> news:...
>>> "Paul" <> 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.)
>>>
>> And what part of this do you interpret to mean ... objects cannot
>> contain 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.
>
> Yes, all it says is that an object is a region of storage. What makes
> you think I think it says anything else?

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" <> wrote in message
news:jUtUo.21958$2...
>
> "Keith Thompson" <kst-> wrote in message
> news:...
>> "Paul" <> writes:
>>> "Keith Thompson" <kst-> wrote in message
>>> news:...
>>>> "Paul" <> 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.)
>>>>
>>> And what part of this do you interpret to mean ... objects cannot
>>> contain 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.
>>
>> Yes, all it says is that an object is a region of storage. What makes
>> you think I think it says anything else?
>
> 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.
>

*function code*

"Paul" <> writes:
> "Keith Thompson" <kst-> wrote in message
> news:...
>> "Paul" <> writes:
>>> "Keith Thompson" <kst-> wrote in message
>>> news:...
>>>> "Paul" <> 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.)
>>>>
>>> And what part of this do you interpret to mean ... objects cannot
>>> contain 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.
>>
>> Yes, all it says is that an object is a region of storage. What makes
>> you think I think it says anything else?
>
> Because you obviously used it as an argument to say that I was wrong.

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.

--
Keith Thompson (The_Other_Keith) kst- <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"

-----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 that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNIpXEAAoJEO0SzzQOdchNWoUQAI3CnS8deH izqen3Huw3hx2z
/5UFww98H121kMagrpFWJ12c+Ps188IX/GSE+yxzNwoN8L+jRkwsQ7nvAUVTCCfh
a3eMLq7m2KVkJvTrpx5LnIgIw52DZfdO2wk3V6fIlRmji/Iu1/zYDrD467DvIzaB
J6VhfDW5t5wcaj4NpydZmdDkZXXR/YEA/vETxLm7upvSLlHwNIajtAgfbu9pDkwx
Hu0ToVJ1OWY8h7v2wK6dPPEFmhaDlHoQhwc8UKu8nE+VRT7FXP XnkW3Mkmr6mXFl
82PdTAglH895fXo1P25EfwO0Y8m0zwffSCopj2xBjR2N6NdDxJ/bVXbn4TINSL6S
XNA50HUFEdDPgErF9phpSLLT+eTdbahdF4rWPcGMHTu3sW28Oy EY8m1L91mwPJ4A
TJP8oOO9LBhgi3XWVOM6hG5TNuiMAORDb+v6MsQ2oYUeWZJxTK bhR0ld5vY7eG5k
b+dSkob++h0cMoBv0N0TR6pk2MQxpBamJDF69dcAgNExKf2kBc h2WS9NHdYOUmgQ
RpmvrMSsbdUkIQrB5sh6ekUSAadpdeUPJK9TAOnIsMiU6okGhv vUVRSBFyGXw1O1
7jctsnUyE0A2Ze53Z0VhQXSipxnp88dC11Xqv7MSGA1f6kLvkA Pc+8TaIxb+MT+M
A1Vcg296ZCGjBMY0aIKs
=HmoI
-----END PGP SIGNATURE-----

"Keith Thompson" <kst-> wrote in message
news:...
> "Paul" <> writes:
>> "Keith Thompson" <kst-> wrote in message
>> news:...
>>> "Paul" <> writes:
>>>> "Keith Thompson" <kst-> wrote in message
>>>> news:...
>>>>> "Paul" <> 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.)
>>>>>
>>>> And what part of this do you interpret to mean ... objects cannot
>>>> contain 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.
>>>
>>> Yes, all it says is that an object is a region of storage. What makes
>>> you think I think it says anything else?
>>
>> Because you obviously used it as an argument to say that I was wrong.
>
> 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.
>
No it implies that a function might occupy storage in the same way , you
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.
>
I use these words as defined in the english dictionary , how do you use
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!

"Paul" <> writes:
> "Keith Thompson" <kst-> wrote in message
> news:...
>> "Paul" <> 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.

--
Keith Thompson (The_Other_Keith) kst- <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"

Paul wrote:
> "Ulrich Eckhardt" <> wrote in message
> news:...
>> 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.

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.