Re: Translating OO program to procedural program

"Tommy Thorn" <tommy.thorn@gmail.com>
11 Oct 2006 23:23:15 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: Translating OO program to procedural program napi@axiomsol.com (napi) (2006-10-11)
Re: Translating OO program to procedural program mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-10-11)
Re: Translating OO program to procedural program torbenm@app-6.diku.dk (2006-10-11)
Re: Translating OO program to procedural program englere_geo@yahoo.com (Eric) (2006-10-11)
Re: Translating OO program to procedural program DrDiettrich1@aol.com (Hans-Peter Diettrich) (2006-10-11)
Re: Translating OO program to procedural program int2k@gmx.net (Wolfram Fenske) (2006-10-11)
Re: Translating OO program to procedural program tommy.thorn@gmail.com (Tommy Thorn) (2006-10-11)
Re: Translating OO program to procedural program JoachimPimiskern@web.de (Joachim Pimiskern) (2006-10-12)
Re: Translating OO program to procedural program gnorik@gmail.com (2006-10-24)
| List of all articles for this month |

From: "Tommy Thorn" <tommy.thorn@gmail.com>
Newsgroups: comp.compilers
Date: 11 Oct 2006 23:23:15 -0400
Organization: Compilers Central
References: 06-10-039
Keywords: OOP
Posted-Date: 11 Oct 2006 23:23:15 EDT

moop wrote:
> I am working on a project translates OO programs to procedural
> programs, such as translating C++ to C and the like. I hope this
> effort can be spreaded out to other langs, so I am working on to
> abstract the common issues of doing so. I know there is a pinoneer
> attempt is C Front which produce C++ programs via a C compiler, I want
> to have a look on that, but still cannot find it now, anyone can
> suggest this to me?


I suggest writing an interpreter first. Once it works, you're
understand all/most of the issues and writing an interpreter is much
easier.


> My approach is just to rename the methods with the instance name so
> that they can be placed in a single source file and then be compiled
> later by the procedural lang compiler.


As a general approach to compiling C++ to C this approach won't work.
Granted, as an optimization, specializing member functions to
particular instances is _sometimes_ worthwhile, but let's crawl before
we run.


Class declarations open up a new name space. To represent such a name
in a flat name space such as globals in C, you'd have to flatten it,
say prefix in some manner with the class name. Your example below
could be void A_run(). In practice, C++ compilers to try guard against
linking type incompatible code, so they encode the type of the method
and it's parameters in the name as well, leading to unreadable
"mangled" names.


The key thing about methods is that they have a hidden parameter which
is the instance they are applied to. Usually this is called "this" or
"self". Thus, a class like


class A {
    int privated_var;
    final void increment() { ++private_var; }
};


could be compiled to


struct A {
    int private_var;
};
void A_increment(struct A *this) { ++this->private_var; }


Virtual methods and polymorphism adds a bit more complication as in
general you cannot _statically_ (without a global analysis) determine
exactly which method is being called. Enter the vtable. The vtable
entry in every object is a pointer to a table of the virtual method in
effect for this object. This table is shared by all instances of the
same class. Fx. without the "final" above, the result could be
something like the following (the casting is unavoidable as this is not
expressible directly with C's type system):


typedef void (*A_increment_method_type)(struct A *);
enum { A_increment_method };
struct A {
    void **vtable;
    int private_var;
};
void *A_vtable[] = { &A_increment };


And a usage of this, such as, a->increment, could be compiled to


    ((A_increment_method_type)a->vtable[A_increment_method])(a);




Tommy


Post a followup to this message

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