technical correctness

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

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

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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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

tyvm

 

[Paul]

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.

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]

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.

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

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

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.

 

[Paul]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

I think you'll find you can have an array of objects if you choose, each
object being a different entity.
If you cannot understand this please do not make obscure statemets that
imply the negative.

 

[Paul]

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.

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]

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]

"Francis Glassborow" <[email protected]> wrote in message

[snip]

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

 

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

 

[Keith H Duggar]

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]

news:[email protected]...

[...]

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]

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.

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]

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.

 

[Paul]

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.

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

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]

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?

 

[Paul]

An object can contain sub-objects yes; member functions are not
sub-objects.

As I have made clear to Francis glassboro..
An object can contain member subobjects, MEMBER SUBOJECTS are defined in C++
standard. If you choose to ignore this thats up to you.

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.

Nonsense there is no statement in the standards that implies an object to be
SIMPLY a region of storage.
You are twising words in an attempt to make the standards mean what you want
them to mean

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 don't seem to understand that a class is the definition of an object.
The fact that a member function is defined within the class means that the
function is part of that objects definition.

The only thing wooly and innaccurate here seems to be you and a few others.

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

Your speaking nonsnese and you obviously choose to ignore what is defined in
the C++ standards.

I used segments to illustrate that member functions are completely
separate to objects.

Youstill haven't explained what type of program you think uses text and data
segments.

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?

You are the one who is 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.

Yes and I have done so.
The fact that a member function is declared in the scope of a class should
be evident enough.
You seem to think a class has nothing to do with an object however I accept
that a class is the definition of an object. You don't seem to know what you
are talking about.

 

[Paul]

Don't confuse Intel segment registers with "program segments"; they are
not the same thing.

/Leigh

Are you now trying to say that an object resides in the same memory region
as its calling program?

I think your attempt to define a program in terms of text and data segments
is irrellevent here and probably very incorrect.