member functions

[Paul]

Aw, c'mon, it lists all possible things an object can contain. Is a member
function among those?



Read up on the so-called "empty baseclass optimization", it allows objects
to effectively use no additional storage.



You quoted the definition of a subobject elsewhere already, it is an
object and thus all restrictions of what constitutes an object apply. Also
note that the above describes classes, not objects, in other words this is
not an argument for or against your case.

This is what the standard gives as a definition of a member subobject.
A class is the definition of an object type therefore I think the standards
are quite correct to define member subobjects as a class.
If you disagree then you disagree with the standards.

Right, exactly that is what you do.



I don't think anybody does. What people keep telling you is that there is
no containment involved in the object/class relationship.

You shunned the above standards definition stating it was referring to
classes an not objects re:
"Also
note that the above describes classes, not objects, in other words this is
not an argument for or against your case."

If the standard defines a member subobject in the context of a class it
reinforces my point that classes and objects are not completely unrelated.

Class/object confusion, read it again.

A class is the definiton of an object, there is no confusion in my mind.
I don't know what your interpretation is but you seem to imply these are two
completely different things.

This does not imply that the function is contained within the object.
Also, not every function call uses dynamic dispatch and requires any
information about the type in the object.

This shows clearly that , in some cases, a pointer to a member function is
actually stored within an object.
The argument is not that functions are stored within an object, the argument
is that member functions are a part of an object as they are defined to be
so in the objects class.

You can consider it part of an object. This distorted view will work in a
few cases, but in other cases it will fail to correctly explain things,
example:

Base b;
Derived d;
b = d;
b.some_function();

Will the last function call invoke Base::some_function() or
Derived::some_function()? If the member functions are part of the object,
copying the object will also copy the functions. However, it doesn't, so
this is something your distorted view doesn't explain. I'm not settling
for your sub-par explanations, and you shouldn't either.

I'm not sure what this is supposed to demonstrate. Other than the already
well known fact that the actual function code is not stored within an
objects region of storage.

 

[Paul]

Please make a full-text search in the above text for the word "object".
Nothing found? Maybe that is because it doesn't describe what an object
is? Do you grasp the difference between a class and an object?

The C++ standard clearly states:
"2 Objects can contain other objects, called subobjects. A subobject can be
a member subobject (9.2),"

The text you refer to above is section 9.2.
The C++ standard makes a clear connection between classes and objects, why
can't you ?

 

[Ian Collins]

The C++ standard clearly states:

Ah, so it's singular now?

 

[Fritz Wuehler]

With all due respect, may I suggest everyone in the group killfile the
argumentative, know-nothing motherfucker Paul like I did, so we don't have
to read his posts? The mind you save may be your own. Why do you waste time
and effort reponding to him when he's clearly an idiot/troll/shit-eater?

Anybody who fucks with Francis G fucks with us! Back off, motherfuckers

 

[Paul]

False. It's part of a class.


You're wrong. Deal with it already - I'm tired of seeing your endless
whining on the subject.

I'm not whining about anything ,
You are the one doing the whining.

The leve of intellect here is simply astonishing

 

[Paul]

in message

With all due respect, may I suggest everyone in the group killfile the
argumentative, know-nothing motherfucker Paul like I did, so we don't have
to read his posts? The mind you save may be your own. Why do you waste
time
and effort reponding to him when he's clearly an idiot/troll/shit-eater?

Anybody who fucks with Francis G fucks with us! Back off, motherfuckers

Another one of Francis' mates I take it.

 

[Paul]

Ah, so it's singular now?

Oh its you again.
It's quite correct to refer to the standards in singular or plural in the
given context.
Do you still disagree?

 

[stan]

I'm not whining about anything ,
You are the one doing the whining.

What references can you cite that support your interpretation of the
word whining?

 

[stan]

I havent shown you anything so far.

I'll have to agree with Paul on this point.

 

[stan]

He compares a function to 'another object'.

So from the statement "an apple is not a brick, and as such cannot
be a part of a load of bricks" you would conclude that an apple is a brick?

Was it the contraction that confused you?

 

[Ulrich Eckhardt]

A class is the definition of an object type therefore I think the
standards are quite correct to define member subobjects as a class.

There are other, non-class object types, so a class is an object type, but
not the object type. Still, objects and classes are distinct in C++. The
parts describing class members are not describing subobjects and vice
versa.

You shunned the above standards definition stating it was referring to
classes an not objects re:
"Also
note that the above describes classes, not objects, in other words this
is not an argument for or against your case."

If the standard defines a member subobject in the context of a class it
reinforces my point that classes and objects are not completely
unrelated.

Unfortunately for you, it doesn't. You are just confused, the standard is
not easy to read.

A class is the definiton of an object, there is no confusion in my mind.
I don't know what your interpretation is but you seem to imply these are
two completely different things.

Right. A class is not an object, an object is not a class.

[dynamic dispatch]

This shows clearly that , in some cases, a pointer to a member function
is actually stored within an object.
The argument is not that functions are stored within an object,

Oh, you changed your mind on that? Last I looked you were adamant that
objects contain member functions.

the argument is that member functions are a part of an object as
they are defined to be so in the objects class.

Since an object in C++ is defined as a region of storage, the member
functions are part of that region of storage. Something here doesn't make
sense.

I'm not sure what this is supposed to demonstrate. Other than the
already well known fact that the actual function code is not stored
within an objects region of storage.

It demonstrates that no reference to a function is stored in the object,
otherwise the call would change targets with the assignment, too.

 

[Bart van Ingen Schenau]

The definition of an Object type. Generally referred to as a class.

Then you got the definition of the term 'object type' wrong. There are
more kinds of object types than just classes. For example, integers
and pointers are also object types.

I don't have the standard here to provide the exact definition, but
'object type' is roughly defined as "a type that describes the
properties of objects".

Bart v Ingen Schenau

 

[Michael Doubez]

Then you got the definition of the term 'object type' wrong. There are
more kinds of object types than just classes. For example, integers
and pointers are also object types.

I don't have the standard here to provide the exact definition, but
'object type' is roughly defined as "a type that describes the
properties of objects".

§1.8/1 [...] 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.

And related to object

§5/7 An expression designating an object is called an object-
expression.

§5.2.5/2 For the first option (dot) the type of the first expression
(the object expression) shall be “class object” (of a complete type).
For the second option (arrow) the type of the first expression (the
pointer expression) shall be “pointer to class object” (of a complete
type). In these cases, the id-expression shall name a member of
the class or of one of its base classes. [Note: <snip>] [Note: 3.4.5
describes how names are looked up after the . and -> operators. ]

And finally:

1 In a class member access expression (5.2.5), if the . or -> token is
immediately followed by an identifier followed by a < [snip template
or compare]. The identifier is first looked up in the class of the
object expression. If the identifier is not found, it is then looked
up in the context of the entire postfix-expression and shall name a
class or function template. If the lookup in the class of the object
expression finds a template, the name is also looked up in the context
of the entire postfix-expression and
— if the name is not found, the name found in the class of the object
expression is used, otherwise
— if the name is found in the context of the entire postfix-expression
and does not name a class template, the name found in the class of the
object expression is used, otherwise
— if the name found is a class template, it must refer to the same
entity as the one found in the class of the object expression,
otherwise the program is ill-formed.

So, for the call of a member function, "the identifier is first looked
up in the class of the object expression"

For all the good it will do to.
You can lead a horse to water, but you can't make it drink

 

[James Kanze]

"Ulrich Eckhardt" <[email protected]> wrote in message

Paul Reid

The C++ standard clearly states:
"2 Objects can contain other objects, called subobjects.
A subobject can be a member subobject (9.2),"

Which, of course, says nothing about classes.

The text you refer to above is section 9.2.
The C++ standard makes a clear connection between classes and
objects, why can't you ?

Where does it make this clear connection? An object has a type,
yes, but that's about it. (And as it happens, only objects with
a class type can contain subobjects. But that's really
incidental to the discussion.)

Do you understand the difference between types and variables?

 

[James Kanze]

Then you got the definition of the term 'object type' wrong. There are
more kinds of object types than just classes. For example, integers
and pointers are also object types.

I don't have the standard here to provide the exact definition, but
'object type' is roughly defined as "a type that describes the
properties of objects".

"Object type" is a subset of "type". A type can be an object
type, a function type or a reference type. Or perhaps something
else which I've forgotten, but those are the three principle
types of types. An object has object type (or perhaps rather,
an entity which has object type is an object). An object can
contain subobjects (which must be objects). As far as the C++
standard is concerned, that's it.

 

[Drew Lawson]

Which, of course, says nothing about classes.


Where does it make this clear connection? An object has a type,
yes, but that's about it. (And as it happens, only objects with
a class type can contain subobjects. But that's really
incidental to the discussion.)

Do you understand the difference between types and variables?

[Assuming for the moment that Paul is not just a piece of performance art.]

The flow and which bits he keeps re-quoting has me wondering whether
he is attaching extra meaning to the "member" in "A subobject can
be a member subobject." I don't have a copy of the standard, so I
can't clarify the meaning of "member subobject."

Section 9.2 looks to define class members, not subobjects.

(I'd guess, but this thread has more than enough of that.)

 

[Paul]

The definition of an Object type. Generally referred to as a class.

Then you got the definition of the term 'object type' wrong. There are
more kinds of object types than just classes. For example, integers
and pointers are also object types.

I don't have the standard here to provide the exact definition, but
'object type' is roughly defined as "a type that describes the
properties of objects".


....................................................................
Section 9.2
"2 A class is considered a completely-defined object type (3.9) (or complete
type) at the closing } of the
class-specifier."


Obviously we are talking about object types as objects defined by classes,
that contain member functions etc.
To say that an integer is also an object, as sometimes used in the context
of the standards, seems to suggest that you are nothing more than a
brainless idiot.
Whether you are or not will be probably be proven by your next post, if
there is one.

 

[Paul]

A class is the definition of an object type therefore I think the
standards are quite correct to define member subobjects as a class.

There are other, non-class object types, so a class is an object type, but
not the object type. Still, objects and classes are distinct in C++. The
parts describing class members are not describing subobjects and vice
versa.

You shunned the above standards definition stating it was referring to
classes an not objects re:
"Also
note that the above describes classes, not objects, in other words this
is not an argument for or against your case."

If the standard defines a member subobject in the context of a class it
reinforces my point that classes and objects are not completely
unrelated.

Unfortunately for you, it doesn't. You are just confused, the standard is
not easy to read.

A class is the definiton of an object, there is no confusion in my mind.
I don't know what your interpretation is but you seem to imply these are
two completely different things.

Right. A class is not an object, an object is not a class.

[dynamic dispatch]

This shows clearly that , in some cases, a pointer to a member function
is actually stored within an object.
The argument is not that functions are stored within an object,

Oh, you changed your mind on that? Last I looked you were adamant that
objects contain member functions.

the argument is that member functions are a part of an object as
they are defined to be so in the objects class.

Since an object in C++ is defined as a region of storage, the member
functions are part of that region of storage. Something here doesn't make
sense.

I'm not sure what this is supposed to demonstrate. Other than the
already well known fact that the actual function code is not stored
within an objects region of storage.

It demonstrates that no reference to a function is stored in the object,
otherwise the call would change targets with the assignment, too.

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call: The function to be called depends on the type of
the object for which it is called. This type cannot in general be determined
until run time. Typically, the pointerp will be of some base classB and the
object will be an object of some derived classD (as was the case with the
base classshape and the derived classcircle above). *The call mechanism must
look into the object and find some information* placed there by the compiler
to determine which functionf is to be called. "


I think the general public would be in agreement with what Bjarne has
written here.
I think its quite apparent that *your* interpretation of the C++ programming
language is nothin more than a sloppy misunderstanding. This, and your
insults towards my mother, suggest you are a person of very low
intelligence.

 

[Paul]

Which, of course, says nothing about classes.


Where does it make this clear connection?

If section 9.2 refers to classes and the above quote re:
"2 Objects can contain other objects, called subobjects. A subobject can be
a member subobject (9.2),"
refers to section 9,2 then there is a connection.


Perhaps because the connection is spread across 2 different pages it may be
too much for your miniscule brain to take in and you are unable to make the
connection.

 

[James Kanze]

news:[email protected]...

[...]
Actually, it doesn't demonstrate anything except maybe that
objects never change type.

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call: The function to be called depends on
the type of the object for which it is called. This type
cannot in general be determined until run time. Typically, the
pointerp will be of some base classB and the object will be an
object of some derived classD (as was the case with the base
classshape and the derived classcircle above). *The call
mechanism must look into the object and find some information*
placed there by the compiler to determine which functionf is
to be called. "

I think the general public would be in agreement with what
Bjarne has written here.

Yes, but it doesn't seem relevant to anything we've been
discussing. (Strictly speaking, of course, it's also not
correct; other mechanisms of handling virtual functions are
possible. But it does correspond to usual practice.) No one is
denying that any specific object has a type. And that virtual
function call resolution depends on that type. The fact that an
object has a type, however, doesn't make it a type.