virtual and class size

[Christopher]

Is the following correct?
----
Question:
On a 32 bit machine, if you have a class A with one int (or DWORD) as
member data, along with a virtual destructor and one other virtual
method, what will the sizeof(A) return?

Answer:
The sizeof function returns the size of a type in bytes.

With no virtual methods, sizeof(type) returns the sum of the class'
data members. However, when you make one or more methods virtual, the
class now carries with it a pointer to the class' vtable.

The answer is therefore, 4 bytes for the int + 4 bytes for the pointer
to the vtable = 8 bytes.
----
What exactly does the vtable look like and how are methods "looked
up"?
The class just contains a pointer to the vtable? I thought each method
had a pointer into the vtable...

I wrote my test program and sure enough I got 8. I flubbed this on an
interview recently, so I want to make sure I've got it down for next
time.

 

[Paul]

Is the following correct?
----
Question:
On a 32 bit machine, if you have a class A with one int (or DWORD) as
member data, along with a virtual destructor and one other virtual
method, what will the sizeof(A) return?

Answer:
The sizeof function returns the size of a type in bytes.

With no virtual methods, sizeof(type) returns the sum of the class'
data members.

Plus padding for alignment.
The following two structs are different sizes on my pc:

struct S1{
char d1;
int d2;
char d3;
char d4;
};

struct S2{
int d2;
char d3;
char d4;
char d1;
};

int main() {
std::cout<< sizeof(S1) << std::endl << sizeof(S2);
}


//output:
12
8

Calculating vtable size gets a bit complicated with multiple
inheritance. I don't think anything is defined in the standard for
implementation of virtual functions.

 

[Goran]

Is the following correct?
----
Question:
On a 32 bit machine, if you have a class A with one int (or DWORD) as
member data, along with a virtual destructor and one other virtual
method, what will the sizeof(A) return?

Answer:
The sizeof function returns the size of a type in bytes.

Actually, the correct answer is: result is not specified by anything
in C++ language.

Seriously, interview question makes way too many assumptions about
language implementation, software and hardware characteristics of the
system.

That said, in typical implementations... (see below)

With no virtual methods, sizeof(type) returns the sum of the class'
data members. However, when you make one or more methods virtual, the
class now carries with it a pointer to the class' vtable.

The answer is therefore, 4 bytes for the int + 4 bytes for the pointer
to the vtable = 8 bytes.

(in typical implementations...)

It's just an array of pointers to virtual functions. E.g.

class x
{
public:
virtual foo();
virtual bar();
int data_member;
};

will have (imaginary code)

void* x_vtable[] = (&x::foo, &x::bar);

instances of "x" will look, in memory, like this:

address_of_x_vtable (4 bytes)
[optional padding, typically no padding for pointer-sized data]
storage_for_data_member (4 bytes)

Suppose you had this:

class x_base
{
int data_member;
};

class x : public x_base
{
virtual foo();
virtual bar();
}

In this case (again, typically), instances of "x" will look, in
memory, like this:

storage_for_data_member (4 bytes)
[optional padding]
address_of_x_vtable (4 bytes)

The class just contains a pointer to the vtable? I thought each method
had a pointer into the vtable...

No, that makes no sense (or at least, it's inefficient). Every class
instance has a pointer to a vtable instead. (typically...) When
compiling, when compiler sees a call to e.g. foo, it generates code to
go to first member of the vtable and call address found there. Why
first member? (again, typically...) Because that's how virtual methods
were ordered in source.

Goran.

 

[Juha Nieminen]

Is the following correct?
----
Question:
On a 32 bit machine, if you have a class A with one int (or DWORD) as
member data, along with a virtual destructor and one other virtual
method, what will the sizeof(A) return?

Answer:
The sizeof function returns the size of a type in bytes.

With no virtual methods, sizeof(type) returns the sum of the class'
data members. However, when you make one or more methods virtual, the
class now carries with it a pointer to the class' vtable.

The answer is therefore, 4 bytes for the int + 4 bytes for the pointer
to the vtable = 8 bytes.

The size is completely up to the implementation. The standard poses no
requirements on this. The size could well be 4 bytes (if the compiler could
somehow implement the requirements of the virtual destructor by means other
than with a vtable pointer in the object) or 400 bytes, for all the standard
cares.

In practice you are correct. However, if your goal is to write completely
portable code, you can't make the assumption.

What exactly does the vtable look like and how are methods "looked
up"?
The class just contains a pointer to the vtable? I thought each method
had a pointer into the vtable...

The exact implementation of virtual tables (which are btw not specified
in any way by the standard; in fact, you could implement dynamic binding
by a completely different method and it would be ok) is probably quite
dependent on the specific compiler.

The basic idea with virtual tables is that they contain function
pointers at specific offsets (which the compiler knows). Each virtual
table in an inheritance hierarchy contains the pointer for a specific
function always at the same offset. This way when a piece of code calls
a virtual function using an object, what happens is that the code takes
the vtable pointer, indexes it with the known literal offset, and calls
the function pointed by that element in the vtable.

So when you do a "myObject->virtualfunc(param)", what the compiler
produces is something akin to "(*myObject.vtable[12])(param)" (where
'vtable' refers to the vtable pointer inside the object, usually at
offset 0).

 

[James Kanze]

[Just nits...]

The vtable looks like what the compiler wants it to look like. A
common implementation is that the vtable is an array of pointers to
all of the virtual functions in a class,

Plus a pointer to the rest of the RTTI information. And
depending on the implementation, the pointer to the virtual
function might also contain a value used to fix up the this
pointer.

and one exists for the base
class and for every derived class.

Conceptually, there should be a vtable for the most derived
class, and for each of the base classes in the most derived
class, e.g.:

struct B1 { virtual ~B1(); };
struct B2 : B1 {};
struct B3 { virtual ~B3(); };
struct D : B2, B1 {};

Conceptually, there is a vtable for B1 in D, B2 in D, B3 in D
and D. The vtables B1 in D, B2 in D and B3 in D will be
different than those for B1, B2 and B3 as most derived classes.

Practically, the compiler will be able to merge some of these
(B1, B2 and D in most implementations.)

Virtual inheritance, of course, only makes the issue more
complex.

 

[Noah Roberts]

What exactly does the vtable look like and how are methods "looked
up"?
The class just contains a pointer to the vtable? I thought each method
had a pointer into the vtable...

I wrote my test program and sure enough I got 8. I flubbed this on an
interview recently, so I want to make sure I've got it down for next
time.

In my experience, and others may vary, you should be thankful that you
"flubbed" this question. People who ask these kinds of trivia
questions are generally not fun to work with or for. They tend to
lack real knowledge in software development, instead having a brain
full of trivial facts that they may not even understand fully. This
is one perfect example, did the person interviewing you understand
that what they THINK the size of the class would be is completely
dependent on a variety of conditions and not anywhere specified by the
language? Probably not.

People ask these kinds of questions when they don't know what else to
ask. This in itself is not a bad thing necessarily since interviewing
people is hard, takes a lot of practice, and you'll fall on your face
a lot. No big deal. But when they fill that lack of knowledge with
questions about esoteric knowledge then there are some things about
them you can figure likely to be true:

1) They want you to fail. I don't think they even realize this is the
case, but they want you to fail so they then feel better about
themselves. "I'm so smart, I can stump everyone that comes to me for
an interview!"

2) They're looking for carbon copies of themselves. Lacking real
leadership experience the only thing they can see as good in a
developer are those things they see in themselves. They know trivial
fact X, therefore any good developer should as well. Recognizing that
trivial fact X is beside the point of almost everything is lost on
them.

3) They write shitty code but think they're brilliant. They very
likely make use of trivial fact X way more often than they need to.
They think you'll need to know these trivia items to survive on their
team, and they may be right. In my experience, people like this
cannot recognize expertise in others and will regularly belittle your
contributions, knowingly or otherwise. They've developed rigid,
absolute ideas that cannot be modified by any form of discussion,
argument, or proof of concept. You might learn a thing or two from
them, but it's more pain than worth really.

A good interview by people who know WTF they're doing will not consist
of a lot of technical questions. Those that do will be at a higher
level than language and hardware trivia. They'll ask you to discuss
some of your recent designs, projects, etc. They'll want to know if
you fit in their culture, not that you've read the C++ standard from
start to finish or know how to hack your implementation. These later
bits can be taught, with the former though you're either a fit or
you're not....people don't generally completely change their
personality for a new job.