member functions

[Paul]

A member functions is part of an object. true or false?

To me a member funtion is part of an object by definition.

However some people like to argue that a member function is not considered
part of an object.. They've suggested that because a function is not stored
within an object in memory thisa is evidence to suggest that an object does
not have member functions.

A member function is definined in an objects class
An objects' class is the definition of an object type and any functions
defined within that class are member of that given object type.
A member function IS by definition a member of an object.

It seems some people cannot see past the fact that a paragraph in the
standards states an object to be a region of memory. They seem to interpet
this to mean that nothing can be part of that object unless it is stored
within the same region of memory.
I have and I still do argue with these people as I think its quite clear
they're view is very narrow minded and not a good way to think about objects
and object types.

 

[Bart van Ingen Schenau]

A member functions is part of an object. true or false?

False.
A member function is part of a class. A class is not the same as an
object, but rather defines a possible type for an object.
A class provides a blueprint for the layout of an object and it tells
the compiler in which constructions an object of that type can be
used.

To me a member funtion is part of an object by definition.

Then you are using different definitions that I am and the other C++
programmers that I know.

However some people like to argue that a member function is not considered
part of an object.. They've suggested that because a function is not stored
within an object in memory thisa is evidence to suggest that an object does
not have member functions.

A member function is definined in an objects class
An objects' class is the definition of an object type and any functions
defined within that class are member of that given object type.
A member function IS by definition a member of an object.

Sorry, but that conclusion does not follow from the preceding
statements.

First, member functions do not have to be defined in a class. It is
also possible to declare members in the class and define them outside
the class.

Secondly, a class provides indeed a definition of an object type, and
any function declared in the class is a member of the class. This is
true for both static and non-static members.

If your conclusion followed logically from the preceding statements,
then static member functions would also be members of an object, even
though they can be used without ever declaring an object of that type.
Additionally, there is a step missing where you show that members of a
class are by necessity also members of an instance of that class,
instead of operating on such an instance.

Bart v Ingen Schenau

 

[Paul]

A member functions is part of an object. true or false?

False.

You are entitled to your opinion.

GL!

 

[Victor Bazarov]

You are entitled to your opinion.

What does it have to do with opinions? A member function is a kind of
function. A function isn't an object, and as such cannot be a part of
another object.

V

 

[Paul]

What does it have to do with opinions? A member function is a kind of
function. A function isn't an object, and as such cannot be a part of
another object.

You refer to functions as objects yet in the same statement you clearly
state a function is not an object.
What you have stated here is nothing more than some twisted double negative

You also seem to have no regard for opinions

 

[Victor Bazarov]

You refer to functions as objects yet in the same statement you clearly

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where?

state a function is not an object.

It is not, and I am basically repeating what the Standard says (see the
first Note in [intro.object/1]).

What you have stated here is nothing more than some twisted double negative

Is English a language you've mastered? Perhaps I ought to use shorter
sentences? Let's try it again:

Only an object can be a part of another object. A function is NOT an
object. Hence a function cannot be a part of an object. There is
nothing in this that is an opinion. Those are just two facts and a
corollary.

You also seem to have no regard for opinions

That's inconsequential to the matter at hand.

V

 

[Ulrich Eckhardt]

A member functions is part of an object. true or false?

In the context of the C++ object model, you have been given the answer
over and over.

Why are you asking again? Just read the existing answers.

To me a member funtion is part of an object by definition.

By what definition?

 

[Ulrich Eckhardt]

You refer to functions as objects yet in the same statement you clearly
state a function is not an object.

He does no such thing.

You also seem to have no regard for opinions

Well, I wouldn't say so, he just doesn't have any for your opinions.

 

[Ney André de Mello Zunino]

Em 06/01/2011 15:03, Victor Bazarov escreveu:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Where?

Judging from what the OP has shown so far, I wouldn't be surprised if he
derived (no pun intended) that conclusion from your sentence: "A member
function is a kind of function." IOW, you must only use the construction
"is a kinf of" to refer to objects in the OO sense; nowhere else. <g>

Haven't all this gone too far? Paul is surely entitled to his opinion. I
just think that his apparent goal of pushing his understanding of the
relationship between member functions and objects in the context of C++
will lead him nowhere.

Regards,

 

[Paul]

He does no such thing.

He compares a function to 'another object'.

Are you people for real.

 

[Paul]

Em 06/01/2011 15:03, Victor Bazarov escreveu:

Judging from what the OP has shown so far,

I havent shown you anything so far.
You are obviously just another hostile asshole who is trying to jump on the
bandwagon.
Please note I object to idiots like you participating in my threads.

 

[Ney André de Mello Zunino]

Em 06/01/2011 15:54, Paul escreveu:

I havent shown you anything so far.
You are obviously just another hostile asshole who is trying to jump on
the bandwagon.
Please note I object to idiots like you participating in my threads.

And yet I was right on the money with my assumption. Thanks for
confirming that. Your trolling efforts had been merely pathetic up to
this point. They've now become predictable and boring.

Worry not. This idiot will not reply to any of your posts from now on.
Have a good one!

 

[Paul]

In the context of the C++ object model, you have been given the answer
over and over.

I have been given 'a' answer not 'the' answer .

Why are you asking again? Just read the existing answers.


By what definition?

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

 

[Paul]

Em 06/01/2011 15:54, Paul escreveu:

And yet I was right on the money with my assumption. Thanks for confirming
that. Your trolling efforts had been merely pathetic up to this point.
They've now become predictable and boring.

Worry not. This idiot will not reply to any of your posts from now on.
Have a good one!

Go away you nasty horrible person .....

 

[Alf P. Steinbach /Usenet]

* Paul, on 06.01.2011 18:52:

He compares a function to 'another object'.

Are you people for real.

Victor just employed a way of speaking where one refers to some other's view.
You can read the last part as a quote or paraphrase, ... like, <<as such cannot
be a "part of another object">> (quoting or paraphrasing you, seeing things from
your point of view). It's funny in its own way, you taking Victor's words
literally, and most people here taking your words literally.

As I wrote earlier, it's just about terminology, and possibly about ways of
thinking about things.

That's mostly off-topic in C++ newsgroups, because that terminology and/or way
of thinking has nothing to do with any particular programming language: you can
think that way and talk that way about things when using Java or Python or
whatever programming language. "Mostly": it can be on-topic to ask whether this
way of talking/thinking is common or suitable for C++ programming, and there you
have your answer, namely that it's not common, and that it is in conflict with
the standard's terminology, i.e. it's easy to misunderstand so it's not suitable
either. So if you want people to understand you, then better define what you
mean, or switch to the common terminology / way of thinking.


Cheers & hth.,

- Alf

 

[Ulrich Eckhardt]

I have been given 'a' answer not 'the' answer .

Sorry, but that's wrong. You have been quoted the relevant section of the
definition all over, you just don't want to or can't listen.

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

To me, too, methods are *generally* part of objects. However, in the
context of the *C++ object model*, it isn't, by its definition the C++
standard.

Do you understand the difference between "in general" and "in the context
of the C++ object model"?

 

[Paul]

* Paul, on 06.01.2011 18:52:

Victor just employed a way of speaking where one refers to some other's
view. You can read the last part as a quote or paraphrase, ... like, <<as
such cannot be a "part of another object">> (quoting or paraphrasing you,
seeing things from your point of view). It's funny in its own way, you
taking Victor's words literally, and most people here taking your words
literally.

As I wrote earlier, it's just about terminology, and possibly about ways
of thinking about things.

That's mostly off-topic in C++ newsgroups, because that terminology and/or
way of thinking has nothing to do with any particular programming
language: you can think that way and talk that way about things when using
Java or Python or whatever programming language. "Mostly": it can be
on-topic to ask whether this way of talking/thinking is common or suitable
for C++ programming, and there you have your answer, namely that it's not
common, and that it is in conflict with the standard's terminology, i.e.
it's easy to misunderstand so it's not suitable either. So if you want
people to understand you, then better define what you mean, or switch to
the common terminology / way of thinking.



--

As with the text from the standards that defines an object as region of
storage. This is incorrectly being retranslated to mean something along the
lines of ...
an object cannot contain a member function.

The standard also states that an object or subobject can be zero size, so
how can a zero sized object be a region of storage? As this demonstrates the
standards are not always simple to interpret, and peraps not always
coherent.


The problem with your argument is that selective quotes or one particular
selective quote is being repeated misquoted to mean something it doesn't
mean.
All other statements in the standards seem to be ignored.
For example paragraph 9.2 to which the standards seem to refer to as the
definition of a member subobject:

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

A member subobject is not necessarily the same thing as an object, defined
as a region of storage.
The term member is self descriptive and automatically implies that it's part
of something.
Another good point here is that the standard refers to class members to
define objects or subobjects, therefore the standards clearly recognise the
relationship between classes and objects , some people shun this idea.


I think this makes my point clear that I am using the terminology as per the
standards.
The fact that a member function is listed where the standard defines the
term member subobject can open up a whole new debate as to whether or not
the standards regard a member function as a membersubobject. But as it
stands it seems to do so.

Please look at this quote from an OOP paper by Bjarne Strousup.

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

The author of the above quote suggests a call mechanism must look into an
object to find some information regarding the function.

All this evidence weighs strongly in favour that a member function can be
considered part of an object.

 

[Paul]

Sorry, but that's wrong. You have been quoted the relevant section of the
definition all over, you just don't want to or can't listen.


To me, too, methods are *generally* part of objects. However, in the
context of the *C++ object model*, it isn't, by its definition the C++
standard.

Do you understand the difference between "in general" and "in the context
of the C++ object model"?

The C++ standards actually suggest that a member function IS part of an
object, when it gives its definition of a member subobject ref:
"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."


You suggest otherwise but you have not provided any quote to reference.
Please can you give a quote from the standards that supports your claim.

 

[Ulrich Eckhardt]

As with the text from the standards that defines an object as region of
storage. This is incorrectly being retranslated to mean something along
the lines of ...
an object cannot contain a member function.

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

The standard also states that an object or subobject can be zero size,
so how can a zero sized object be a region of storage?

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

For example paragraph 9.2 to which the standards seem to refer to as the
definition of a member subobject:

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

A member subobject is not necessarily the same thing as an object,
defined as a region of 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.

All other statements in the standards seem to be ignored.

Right, exactly that is what you do.

Another good point here is that the standard refers to class members
to define objects or subobjects, therefore the standards clearly
recognise the relationship between classes and objects , some people
shun this idea.

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

I think this makes my point clear that I am using the terminology as
per the standards. The fact that a member function is listed where the
standard defines the term member subobject can open up a whole new
debate as to whether or not the standards regard a member function as
a membersubobject. But as it stands it seems to do so.

Class/object confusion, read it again.

Please look at this quote from an OOP paper by Bjarne Strousup.

"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 pointer p will be of some base class B and the object
will be an object of some derived class D (as was the case with the
base class shape and the derived class circle above). The call mechanism
must look into the object and find some information placed there by the
compiler to determine which function f is to be called"

The author of the above quote suggests a call mechanism must look into
an object to find some information regarding the function.

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.

All this evidence weighs strongly in favour that a member function can
be considered part of an object.

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.

 

[Ulrich Eckhardt]

The C++ standards actually suggest that a member function IS part of an
object, when it gives its definition of a member subobject ref:
"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."

You suggest otherwise but you have not provided any quote to reference.

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?