Google Answers Logo
View Question
Q: Translation of C++ classes into assembly ( Answered 5 out of 5 stars,   0 Comments )
Subject: Translation of C++ classes into assembly
Category: Computers > Programming
Asked by: wanderer83-ga
List Price: $10.00
Posted: 09 Mar 2005 07:36 PST
Expires: 08 Apr 2005 08:36 PDT
Question ID: 488746
How are classes translated into machine language? I would like to see
(perhaps with an example) how different parts and aspects are visible
in assembly - for instance what the difference later is in "private"
or "public" or "virtual" and so on. Or are the classes and these
elements (as well as polymorphism) only an abstraction on the
interpreter level (do they disappear later when turned into code?)

Also - another thing is - if we have (in case of Win32) a dll and we
instantiate an object from it - how does that look in machine language
- what exactly happens ?

Thank you for your help

Request for Question Clarification by efn-ga on 10 Mar 2005 19:26 PST
Hi wanderer83,

Considering that this is the topic of a 300-page book, I don't think
you will get a complete answer here.  I can refer you to the book and
give you general, abstract answers on the points you mentioned, but
this will not tell you everything there is to know about the
implementation of classes.  Would you like to buy that answer?  You
are, of course, welcome to hold out for a better offer.

In case it helps you decide, I have had years of assembly language
experience, but not on Intel x86-architecture processors.  I have
worked with assembly-level implementations of C, but not C++.  My
knowledge of C++ implementation is second-hand from reading, not
derived from working on a compiler or studying object code.


Clarification of Question by wanderer83-ga on 13 Mar 2005 20:16 PST
Go for it ! But please - be as detailed as possible. And the book
reference is appreciated !

THe thing I am most interensted in is also instantiating objects from
libraries. How is this done ?
Subject: Re: Translation of C++ classes into assembly
Answered By: efn-ga on 13 Mar 2005 21:44 PST
Rated:5 out of 5 stars
Hi wanderer83,

Thanks for accepting my proposal.

The book I mentioned is "Inside the C++ Object Model" by Stanley B.
Lippman (Addison-Wesley Professional, 1996).

Public, private, and protected access are purely compile-time checks,
like type checking.  You can prove this by bypassing the checks, as in
the following example.

#include <iostream>

class Bypass
	typedef void (Bypass::*memberPointer)();
	memberPointer expose();
	void privateFunction();

Bypass::memberPointer Bypass::expose()
	return &Bypass::privateFunction;

void Bypass::privateFunction()
	std::cout << "privateFunction\n";

int main(int argc, char* argv[])
	Bypass bp;
	Bypass::memberPointer mp = bp.expose();
	char c;
	std::cin >> c;
	return 0;

If you compile and run this, you should see that the main function can
call Bypass::privateFunction, even though it is private.

This design makes sense, as it would impose an intolerable overhead if
every member function call had to include a check on whether the
caller was authorized to call the function.

Virtual functions and polymorphism, however, must have a run-time
manifestation, since the whole idea is to be able to call different
functions depending on the type of an object, which may not be known
until run time.  The usual implementation design uses a virtual
function table.  Any object that has virtual functions contains a
pointer to a virtual function table.  (This pointer is invisible and
inaccessible to the application programmer.)  The pointer to the
virtual function table corresponding to the object's type is set when
the object is constructed.  When a function calls a non-virtual member
function, the compiler knows where the code for that function is and
simply generates code to call it, but when a function calls a virtual
member function, the compiler generates code to pick out a pointer to
the function from the virtual function table addressed by the pointer
in the object.  Then it uses that function pointer to call the
function defined for the object's actual type.

Of course, this gets more complicated with multiple inheritance and
virtual inheritance, but compiler makers have solved these problems

This is just a summary; for more details, see:

C++ FAQ answer on virtual functions (see also the following answer,
which goes into more detail)

An MSDN Magazine answer by Paul DiLascia shows assembly language implementation

Wiki Wiki Web page on VeeTable

To instantiate an object, the run-time code must allocate sufficient
memory for the object and run its constructor.  The memory allocation
may happen at various times, depending on the object's storage class. 
A static object has space allocated at compile (or link) time; an
automatic object has space typically allocated on entry to the block
in which it is defined, and a dynamic object has space allocated from
the free store at construction time.

A constructor is just a function.  It gets an invisible parameter that
tells it where the storage to be initialized is.

It makes no difference if the code for the constructor is in a library
or not.  When the library is linked to the main program, either
statically or dynamically, the program finds out where the constructor
is.  Then it calls it the same way either way.

Additional Link

MSDN Library article "C++:  Under the Hood" by Jan Gray

I hope this information is helpful.  As I said, I can't really explain
the whole C++ object model in this space, but I have tried to provide
general answers on the points you asked about, with links to more
detailed material.  If anything is not clear enough, please ask for a
clarification and I will try to improve my explanation.


wanderer83-ga rated this answer:5 out of 5 stars
That's what I needed - explanation of general concepts and lots of
useful links. Great job !

There are no comments at this time.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  

Google Home - Answers FAQ - Terms of Service - Privacy Policy