Re: Class representation in memory

McMalo <McMalo@HotMail.com> writes:
>I am looking for any literature about Class representation in memory.
>How a compiler/interpreter builds this stuff in memory, and how it
>manages it.


If you're referring specifically to C++, I can give you a very rough
idea of how the representation proceeds in terms of how the class
would look in C.


Ignoring all the complexities of C++, the basics are that: a class is
essentially a structure that is associated with a set of functions.
If the class is called "class K", the corresponding structure might be
defined by:


typedef struct sK *K;


The member functions are not fields in the structure. Instead, if
f(...) is a member function, its equivalent parametrization in C would
run something like: f(K this, ...) or equivalently f(struct sK *this,
...). This is just one function which is stored in memory, not one
function for each structure of type K used in the program!


If k is a pointer to the class, then the function call k->f(...)
would correspond to f(k, ...) in C.


The instance-formation function would have a definition looking
something like this:


K NewK(...) {
      K *this = malloc(sizeof *this);
      error handling
      ...
      return this;
}


with a C++ <-> C correspondence like this: new K(...) <--> NewK(...);


The instance-deletion function would have a definition looking
something like this:


DeleteK(K this, ...) {
      ...
      free(this);
}


with a C++ <-> C correspondence like this: delete K(...) <--> DeleteK(...);


The public, private and protected attributes (for the most part) would
be invisible to C, except maybe representing a private member function
as a "static" function, if the class can be encapsulated in a single
file. It's relevant only for compile-time semantic filtering, error
checking and the like, not for memory storage.


An interesting observation is that it should be possible to extend C
(to a new ANSI-2001 C) with the addition of the compile-time type
checking that include all these C++ niceties in such a way that a
direct C++ -> ANSI-2001 C conversion is possible in which all semantic
constraints in the source language are preserved intact.


(Of course, the reason you'll extend C in the presence of a superset
like C++ is because (1) C is simpler, (2) to incorporate all the
niceties of C++ without losing C's simplicity and (3) to incorporate
source-level concurrency/task-switching primitives as a superset of
<setjmp.h>).

Return to the comp.compilers page.
Search the comp.compilers archives again.