technical correctness

[Paul]

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.

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]

[...]
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.

 

[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.
[...]

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.

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]

[...]
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.

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*

 

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

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?

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.

The words mean what they mean.

Yes, they do. I wish I could help you to understand that.

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.

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]

-----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/

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]

[...]
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?

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.

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?

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.

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.

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]

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.

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

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

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]

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.

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]

[...]

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]

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]

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

 

[Michael Doubez]

    [...]

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

[snip]

 

[Paul]

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.

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

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

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?

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?

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]

-----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]

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.

 

[Paul]

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.

 

[Michael Doubez]

Ok. On first reading, I didn't catch that a compiler issuing an error
for undefined unused functions would not be standard compliant.

I'm not having any problems.





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.

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.

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

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.

 

[Bart van Ingen Schenau]

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