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]

Re: class method representation

emerth wrote:
[color=blue]
> 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?[/color]

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]

Re: class method representation

emerth wrote:
[color=blue]
> 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.[/color]

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]

Re: class method representation

emerth <emerth@hotmail .com> wrote in message
news:a95ba2e0.0 308071429.39e57 25b@posting.goo gle.com...[color=blue]
> 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.[/color]

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

[David White]

Re: class method representation

E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:3F32DFDA.6 090109@jpl.nasa .gov...[color=blue]
> emerth wrote:
>[color=green]
> > 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.[/color]
>
> Objects do *not* have, include or contain methods.[/color]

Conceptually they do. If I say ellipse.Area(), I am asking _that_ ellipse
for its area.
[color=blue]
> Not in C++ or any other object oriented programming language.[/color]

It was a while ago, but I recall methods in Smalltalk being fully fledged
objects.
[color=blue]
> The methods belong to the class.[/color]

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

DW

[E. Robert Tisdale]

Re: class method representation

David White wrote:
[color=blue]
> For the purposes of the language rules, it's best[/color]

It is *not* best. It is not true
and it leads to the kind of confusion expressed by emerth.
[color=blue]
> to think of each object as having
> its own copy of each non-static data and function member.[/color]

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!
[color=blue]
> 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 about your code growing
> every time you create an object.[/color]

[David White]

Re: class method representation

E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:3F32EBC4.7 0401@jpl.nasa.g ov...[color=blue]
> David White wrote:
>[color=green]
> > For the purposes of the language rules, it's best[/color]
>
> It is *not* best. It is not true
> and it leads to the kind of confusion expressed by emerth.[/color]

I shouldn't have said "language rules". I meant that in terms of OO
programming it makes sense to think of it that way.
[color=blue][color=green]
> > to think of each object as having
> > its own copy of each non-static data and function member.[/color]
>
> No. This would imply that you could mix and match methods[/color]

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]

Re: class method representation

David White wrote:
[color=blue]
> Not really. It just means that when you call a method for an object,
> it behaves as though it's the object's method.[/color]

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]

Re: class method representation

David White wrote:
[color=blue]
> E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
> news:3F32EBC4.7 0401@jpl.nasa.g ov...
>[color=green]
>>David White wrote:
>>[color=darkred]
>>>For the purposes of the language rules, it's best[/color]
>>
>>It is *not* best. It is not true
>>and it leads to the kind of confusion expressed by emerth.[/color]
>
> I shouldn't have said "language rules". I meant that in terms of OO
> programming it makes sense to think of it that way.[/color]

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.

--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"

[David White]

Re: Off Topic: class method representation

E. Robert Tisdale <E.Robert.Tisda le@jpl.nasa.gov > wrote in message
news:3F3300B1.8 080604@jpl.nasa .gov...[color=blue]
> David White wrote:
>[color=green]
> > I mean that in Smalltalk methods are objects.[/color]
>
> C functions are objects as well.
>[color=green]
> > Classes are also objects,[/color]
>
> No. In smalltalk (and Java),[/color]

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."
[color=blue]
> 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.[/color]

DW

[David White]

Re: class method representation

Corey Murtagh <emonk@slingsho t.co.nz.no.uce> wrote in message
news:1060308449 .558900@radsrv1 .tranzpeer.net. ..[color=blue]
> In another post on this thread you said: "I think of a class as an
> object blueprint."[/color]

That's right.
[color=blue]
> Your analogy, however useful you may find it, is fundamentally flawed.
> Conceptually, a blueprint is the instructions for building something.[/color]

Yes, in this case on object of that class. The class defines the object's
data and behaviour.
[color=blue]
> 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.[/color]

The class defines completely how an instance of it will behave. That's why I
called it a blueprint. It's an appropriate analogy.
[color=blue]
> 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[/color]

It isn't sloppy at all.
[color=blue]
> 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.[/color]

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