class method representation

[emerth]

I am curious about the structure of a C++ object.

Classes have methods, and data. Different instances of
a class will have their own data variables (yes, unless
I define a variable to be common, but let us say I did not
do that).

My question is this: does each instance have it's own
copy of the non-static methods?

Maybe this is a dumb question, but what motivates it is
this:

Say I have a class with a really huge complicated method
and I will be instantiating many, many objects of this class.
If each instance gets it's own copy of the huge method code,
then I might save some memory by modifying the method to
be a function (eg not a class method) and have only one
copy of it around.

 

[Dimitris Kamenopoulos]

I am curious about the structure of a C++ object.

Classes have methods, and data. Different instances of
a class will have their own data variables (yes, unless
I define a variable to be common, but let us say I did not
do that).

My question is this: does each instance have it's own
copy of the non-static methods?

Usually not. What happens is that every method is converted (by the
compiler) to a "normal" function that accepts the "this" pointer to the
object instance it manipulates.

For instance, in this example:

1 int i;
2 std::string s = ...;
3 char c = s.at(i);

the compiler will actually generate for line 3 something like

char c = std::string::at(&s, i);

Of course inlining a function complicates matters slightly, but even then,
you basically get a copy of the function per function call, not a copy of
the function per object.

But try it yourself; write two classes with identical data members and
different methods (in number and "size") and compare their sizes with the
sizeof() operator.

 

[E. Robert Tisdale]

I am curious about the structure of a C++ object.

Classes have methods, and data. Different instances of
a class will have their own data variables
(yes, unless I define a variable to be common,
but let us say I did not do that).

My question is this: does each instance have
it's own copy of the non-static methods?

Maybe this is a dumb question
but what motivates it is this:

Say I have a class with a really huge complicated method
and I will be instantiating many, many objects of this class.
If each instance gets it's own copy of the huge method code,
then I might save some memory
by modifying the method to be a function (e.g. not a class method)
and have only one copy of it around.

Objects do *not* have, include or contain methods.
Not in C++ or any other object oriented programming language.
The methods belong to the class. If there are virtual functions,
the object will contain a pointer to an array of function pointers
called the virtual function table. The function pointers
point to the methods which belong to the same class as the object.

 

[David White]

I am curious about the structure of a C++ object.

Classes have methods, and data. Different instances of
a class will have their own data variables (yes, unless
I define a variable to be common, but let us say I did not
do that).

My question is this: does each instance have it's own
copy of the non-static methods?

Maybe this is a dumb question, but what motivates it is
this:

Say I have a class with a really huge complicated method
and I will be instantiating many, many objects of this class.
If each instance gets it's own copy of the huge method code,
then I might save some memory by modifying the method to
be a function (eg not a class method) and have only one
copy of it around.

For the purposes of the language rules, it's best to think of each object as
having its own copy of each non-static data and function member. In effect,
that's what you get. However, in a given executable file, the actual
implementation will almost certainly share the same code among all objects,
so you don't have to worry your code growing every time you create an
object.

DW

 

[E. Robert Tisdale]

For the purposes of the language rules, it's best

It is *not* best. It is not true
and it leads to the kind of confusion expressed by emerth.

to think of each object as having
its own copy of each non-static data and function member.

No. This would imply that you could mix and match methods
from other classes freely which is *not* true.
The methods belong to the class of which the object is an instance.
No substitutions are allowed!

 

[David White]

Objects do *not* have, include or contain methods.

Conceptually they do. If I say ellipse.Area(), I am asking _that_ ellipse
for its area.

Not in C++ or any other object oriented programming language.

It was a while ago, but I recall methods in Smalltalk being fully fledged
objects.

The methods belong to the class.

Then I can call Ellipse::Area() without an object, which I can't.

DW

 

[David White]

It is *not* best. It is not true
and it leads to the kind of confusion expressed by emerth.

I shouldn't have said "language rules". I meant that in terms of OO
programming it makes sense to think of it that way.

No. This would imply that you could mix and match methods

Not really. It just means that when you call a method for an object, it
behaves as though it's the object's method.

DW

 

[E. Robert Tisdale]

Not really. It just means that when you call a method for an object,
it behaves as though it's the object's method.

No.
It behaves as though it's the class's method.
Objects which belong to the same class
do *not* invoke different methods.

 

[Corey Murtagh]

I shouldn't have said "language rules". I meant that in terms of OO
programming it makes sense to think of it that way.

In what way does it 'make sense' to use such a flawed concept?

In another post on this thread you said: "I think of a class as an
object blueprint."

Your analogy, however useful you may find it, is fundamentally flawed.
Conceptually, a blueprint is the instructions for building something.
The closest thing in C++ is a template - which is in effect a blueprint
for building classes. A class on the other hand is a collection of code
plus a data format. It's that data format which is the blueprint for
building objects, and it contains no code of its own.

As Robert pointed out, sloppy analogies and concepts like the one you're
espousing only lead to confusion. Code and static data members belong
to the class, and non-static data belongs to the instance.

 

[David White]

C functions are objects as well.


No. In smalltalk (and Java),

My recollection is that everything is an object in Smalltalk.
From the Smalltalk/V manual and encyclopedia of classes, 1992:
"Classes are also objects contained in global variables which are maintained
in the System Dictionary "Smalltalk".
"Every class is an instance of a metaclass of the same name."

In smalltalk (and Java),
an object is instantiated along with the class definition
that you can reference using the same name as the class.
This extra overhead was deemed acceptable to smalltalk designers
because it simplifies the language definition.

DW

 

[David White]

In another post on this thread you said: "I think of a class as an
object blueprint."

That's right.

Your analogy, however useful you may find it, is fundamentally flawed.
Conceptually, a blueprint is the instructions for building something.

Yes, in this case on object of that class. The class defines the object's
data and behaviour.

The closest thing in C++ is a template - which is in effect a blueprint
for building classes. A class on the other hand is a collection of code
plus a data format.

The class defines completely how an instance of it will behave. That's why I
called it a blueprint. It's an appropriate analogy.

It's that data format which is the blueprint for
building objects, and it contains no code of its own.

As Robert pointed out, sloppy analogies

It isn't sloppy at all.

and concepts like the one you're
espousing only lead to confusion. Code and static data members belong
to the class, and non-static data belongs to the instance.

That's what I call confusing. It implies that the code is indepenent of
instances of the class. It's not. You can _only_ call a non-static member
function in the context of an object. Non-static member functions usually
refer to member variables that are owned by an object, not the class.
Therefore, conceptually the function belongs to the object, not the class.

DW