Object member functions and runtime memory consumption

[He Shiming]

Hi,

I have a question regarding memory consumption of class/object member
functions.

Say that I have:
class A {
char szAbc[16];
char* getString();
}

Then I have:
vector<A> vA;
// vA.resize(100); or populate an array in other ways.

Right there, I understand that there are multiple copies of szAbc in the
memory. But what about the getString() member function? Are there multiple
copies of getString() function code in the memory? What if I have another
vector<A> vA2. Will they share the same function code in the memory?

If not, what do I to force them to share the very same member function code
in the memory?

Thanks in advance,
--
He Shiming

[Jeff Schwab]

He Shiming wrote:

Hi,

I have a question regarding memory consumption of class/object member
functions.

Say that I have:
class A {
char szAbc[16];
char* getString();
}

Then I have:
vector<A> vA;
// vA.resize(100); or populate an array in other ways.

Right there, I understand that there are multiple copies of szAbc in the
memory. But what about the getString() member function? Are there multiple
copies of getString() function code in the memory?
No.

What if I have another
vector<A> vA2. Will they share the same function code in the memory?

Yes.
Each class has (in the canonical implementation) a table of pointers to
the definitions of the class's member functions, so each (non-inline)
function definition only needs to exist in one place. If a class has
virtual methods, though, each instance of the class may be given its own
pointer to the vtable.

[He Shiming]

Thank you for the explanation. That was quite helpful.

--
He Shiming

"Jeff Schwab" <je************ @rcn.com> wrote in message
news:Bv******** ************@rc n.net...

He Shiming wrote:

Hi,

I have a question regarding memory consumption of class/object member
functions.

Say that I have:
class A {
char szAbc[16];
char* getString();
}

Then I have:
vector<A> vA;
// vA.resize(100); or populate an array in other ways.

Right there, I understand that there are multiple copies of szAbc in the
memory. But what about the getString() member function? Are there
multiple copies of getString() function code in the memory?

No.

What if I have another vector<A> vA2. Will they share the same function
code in the memory?

Yes.
Each class has (in the canonical implementation) a table of pointers to
the definitions of the class's member functions, so each (non-inline)
function definition only needs to exist in one place. If a class has
virtual methods, though, each instance of the class may be given its own
pointer to the vtable.

[Malte Starostik]

Jeff Schwab schrieb:

Each class has (in the canonical implementation) a table of pointers to
the definitions of the class's member functions, so each (non-inline)
function definition only needs to exist in one place. If a class has
virtual methods, though, each instance of the class may be given its own
pointer to the vtable.

Not entirely correct. That table of pointers (the vtable) only exists
at all if the function has virtual methods. Otherwise, such a table
only exists at compile time, as part of the compiler's lookup table to
resolve member function calls - however that is implemented exactly
depends on the compiler of course. In the generated code, the a
non-virtual member function call is no different than a free function
call save for the additional "hidden" this argument and maybe a
different way to pass arguments. No vtable indirection involved.

Cheers,
Malte

[Jeff Schwab]

Malte Starostik wrote:

Jeff Schwab schrieb:

Each class has (in the canonical implementation) a table of pointers to
the definitions of the class's member functions, so each (non-inline)
function definition only needs to exist in one place. If a class has
virtual methods, though, each instance of the class may be given its own
pointer to the vtable.

Not entirely correct. That table of pointers (the vtable) only exists
at all if the function has virtual methods. Otherwise, such a table
only exists at compile time, as part of the compiler's lookup table to
resolve member function calls - however that is implemented exactly
depends on the compiler of course. In the generated code, the a
non-virtual member function call is no different than a free function
call save for the additional "hidden" this argument and maybe a
different way to pass arguments. No vtable indirection involved.

Thanks, that's a good point.

I wonder whether a table of pointers to member functions can be forced
to exist in the object code? Ordinary functions can be given external
linkage ("extern"), but what about member functions?

[Malte Starostik]

Jeff Schwab schrieb:

I wonder whether a table of pointers to member functions can be forced
to exist in the object code? Ordinary functions can be given external
linkage ("extern"), but what about member functions?

Non-inline member functions have external linkage already. So they are
included in whatever symbol table is used on a given platform to resolve
any kind of symbols with external linkage. It just won't be (for the
compilers I know) a distinct per-class table. The mangled function name
includes the class name though, so if you need to build such a table,
you can parse the object file yourself to enumerate all symbols and
filter out those not belonging to the class you're interested in :-)

Cheers,
Malte