C++ Object Model

[al.cpwn]

Which sections of the 2003 standard should I study to understand the
object model? I am looking to find information similar to that in
Stanley B. Lippman's book, "Inside the C++ Object Model"

 

[peter koch]

(e-mail address removed) skrev:

Which sections of the 2003 standard should I study to understand the
object model? I am looking to find information similar to that in
Stanley B. Lippman's book, "Inside the C++ Object Model"

If I understand you correctly, no part of the standard will be
relevant. The standard mandates almost nothing w.r.t. the physical
layout of objects (the most important exception being that a
std::vector must be implemented as one contigeous chunk of memory).
One thing that could tell you about a possible implementation of C++ is
the C++ performance report. Google for it.

/Peter

 

[Me]

Which sections of the 2003 standard should I study to understand the
object model? I am looking to find information similar to that in
Stanley B. Lippman's book, "Inside the C++ Object Model"

I'm not really sure what you mean by object model but if it's anything
like the book, these are the things you need to look for in the
standard:

static_cast
dynamic_cast
typeid
virtual functions
virtual members
member function pointers
member data pointers

and how

multiple inheritence
virtual inheritence
private inheritence

interacts with the above

(I believe this is a complete list). The C++ standard just says the
layout of non-POD classes are implementation defined, so if you're
looking for any hints by the standard, you're out of luck. But you
definitely should be aware that C++ allows diamond style inheritence as
pictured in this iostreams chart:
http://www.cplusplus.com/ref/iostream/

 

[al.cpwn]

(e-mail address removed) skrev:


If I understand you correctly, no part of the standard will be
relevant. The standard mandates almost nothing w.r.t. the physical
layout of objects (the most important exception being that a
std::vector must be implemented as one contigeous chunk of memory).
One thing that could tell you about a possible implementation of C++ is
the C++ performance report. Google for it.

/Peter

I recently had an interview for a C++ programmer position and the
interviewer asked me questions like:

where does the virtual table reside? (my answer: in memory)
why don't we make all destructors virtual? (my answer: because they
will cost memory due to vtable and some classes are not designed to be
base classes)
If we add a virtual function to a class will we see an increase in
class size? (i said yes)
While size of class grow at constant rate with the addition of each
virtual function? (i said not sure)

He then paused and gave me some advice on which books to read, saying
that I must read "Inside the C++ Object Model". He also said that I
can't be a good C++ programmer without being a good C programmer. It is
disappointing because I answered each question to the best of my
ability. There were some algorithm problems as well but he criticized
me most for knowledge of C++. So essentially there is no set standard
for how objects should be represented internally?

 

[al.cpwn]

I'm not really sure what you mean by object model but if it's anything
like the book, these are the things you need to look for in the
standard:

static_cast
dynamic_cast
typeid
virtual functions
virtual members
member function pointers
member data pointers

and how

multiple inheritence
virtual inheritence
private inheritence

interacts with the above

(I believe this is a complete list). The C++ standard just says the
layout of non-POD classes are implementation defined, so if you're
looking for any hints by the standard, you're out of luck. But you
definitely should be aware that C++ allows diamond style inheritence as
pictured in this iostreams chart:
http://www.cplusplus.com/ref/iostream/

Thank you, I'll read these and get back with any questions.

 

[benben]

I recently had an interview for a C++ programmer position and the

interviewer asked me questions like:

where does the virtual table reside? (my answer: in memory)

Correct. Static memory most likely.

why don't we make all destructors virtual? (my answer: because they
will cost memory due to vtable and some classes are not designed to be
base classes)
Correct.

If we add a virtual function to a class will we see an increase in
class size? (i said yes)

You have to ask him back what he means by "class size". If what he
refers to is the size of memory allocated for an object of such a class.

If he agrees you have to ask him whether there is already a virtual
function in such a class. If the answer is yes then there is unlikely a
change in "size"; otherwise an increase in the size is possible.

While size of class grow at constant rate with the addition of each
virtual function? (i said not sure)

Again you need a better definition for "class size". If that means the
size of the static memory needed to support such a class (such that
reserved for class information especially concerning the virtual
functions) then the answer is yes. If the term means what I assumed in
the previous paragraph, it is unlikely. Again this is highly
implementation dependent.

He then paused and gave me some advice on which books to read, saying
that I must read "Inside the C++ Object Model". He also said that I
can't be a good C++ programmer without being a good C programmer. It is
disappointing because I answered each question to the best of my
ability. There were some algorithm problems as well but he criticized
me most for knowledge of C++. So essentially there is no set standard
for how objects should be represented internally?

If that's his reason to dismiss you then you may be better off being
dismissed. The interviewer as described seems to have a screw loose in
his head.

Regards,
Ben

 

[Me]

I recently had an interview for a C++ programmer position and the
interviewer asked me questions like:

where does the virtual table reside? (my answer: in memory)

This question assumes the compiler implements virtual functions as an
array of function pointers. The implementations listed in Lippman's
book (from memory and it's been a long while since I last read it) turn
the following:

class foo {
virtual void fn();
data d;
};

into one of (ignoring std::type_info):

// table inlined at the beginning
struct foo {
void (*fn)(foo*);
data d;
};

// table inlined at the end
struct foo {
data d;
void (*fn)(foo*);
};


struct foo_vtbl {
void (*fn)(foo*);
};

// vtable at beginning
struct foo {
const foo_vtbl *vtbl;
data d;
};

// vtable at end
struct foo {
data d;
const foo_vtbl *vtbl;
};

There are tons of other possible choices. One possibility is to keep
track of all RTTI objects in a giant global table and do a lookup based
on the address and then call the desired function based on a switch
statement. This has the advantage of requiring no storage inside the
class at all.

If we add a virtual function to a class will we see an increase in
class size? (i said yes)
While size of class grow at constant rate with the addition of each
virtual function? (i said not sure)

These two questions support my assumption about those 4 implementations
above. You can see that if we inline the table, the class size
increases, but if we use a vtable, the class size stays constant.

For multiple/virtual inheritance with virtual data members this gets
much more complicated and it really depends on how the implementation
ties all the things required by the C++ standard together to see if
adding a virtual function in some base class increases the size.

He then paused and gave me some advice on which books to read, saying
that I must read "Inside the C++ Object Model". He also said that I
can't be a good C++ programmer without being a good C programmer.

This guy sounds like one of those people that gets really familiar with
how their compiler implements things and then makes all sorts of
non-standard conforming/portable assumptions instead of what the
standard actually guarantees. (I'd recommend getting the book though, I
used it to learn C++ but it definitely shouldn't be used as a
substitute for the C++ standard)

It is disappointing because I answered each question to the best of my
ability. There were some algorithm problems as well but he criticized
me most for knowledge of C++. So essentially there is no set standard
for how objects should be represented internally?

A C++ implementation may be required to follow some ABI for backwards
compatibility/interoperability reasons, but as far as the C++ standard
is concerned, the answer is no and the examples given in the book were
pretty much cfront centric and designed to be easily ported. Non-cfront
compilers have the advantage of knowing the machine model and can do
all sorts of evil tricks like using thunks.

 

[peter koch]

(e-mail address removed) skrev:

peter koch wrote: [snip]

I recently had an interview for a C++ programmer position and the
interviewer asked me questions like:

where does the virtual table reside? (my answer: in memory)
why don't we make all destructors virtual? (my answer: because they
will cost memory due to vtable and some classes are not designed to be
base classes)
If we add a virtual function to a class will we see an increase in
class size? (i said yes)
While size of class grow at constant rate with the addition of each
virtual function? (i said not sure)

He then paused and gave me some advice on which books to read, saying
that I must read "Inside the C++ Object Model". He also said that I
can't be a good C++ programmer without being a good C programmer. It is
disappointing because I answered each question to the best of my
ability. There were some algorithm problems as well but he criticized
me most for knowledge of C++. So essentially there is no set standard
for how objects should be represented internally?

Nope - there is no standard layout of objects in C++. It is up to the
implementers of the particular compiler to find the smartest way to
store their data.
Apart from this, I really am not sure that I agree with your
interviewer.... knowledge of C is okay, but if it makes you program as
if you were programming in C, you would have been better off with no
knowledge of C. Still, being aware of what goes on "beneath" the C++
layer is a huge advantage when optimising and debugging programs.

Kind regards
Peter

 

[Student]

Hi all,
I also got a lot of infor on this. But as every body has told it's not
true that C knowledge is required for the C++. I know people starting
from C++ and with no knowledge of C. Well it's a thinking that C++ is a
different language although it started as a superset of C. Well
currently i am trying to implement a subset of C++(As an assignment). I
think i should make it so that people can see what internally happens.
Please provide me comment on how to make it? Like how to design it so
that people can easily understand it. and whicl all things to refer for
it.
Tahnks