Path: utzoo!utgpu!attcan!uunet!lll-winken!ames!pasteur!ucbvax!hplabs!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: What is C++ doing?
Message-ID: <6590133@hplsla.HP.COM>
Date: 24 May 89 17:40:49 GMT
References: <2671@ssc-vax.UUCP>
Organization: HP Lake Stevens, WA
Lines: 59

>   I think I have a pretty good handle on the basics of oop and C++,
> but what I'd like to know is *how* C++ is implemented.  I have
> Glockenspiel C++ on an Apollo, but I don't know how to get the
> "compiler" to let me see it's C output.  (Anybody know?)

Depending on the compiler, I've used a number of different techniques
to do this.  One simple way is to wait for an indication that "cc"
is executing, then abort the compile.  In my case, this would leave
behind a ..c file with the intermediate C code.  Some compilers may
have a -F or -Fc option that directs intermediate C code to standard
output.  Or they may have a +i option to leave behind the intermediate
C file after compilation.

Once you have the intermediate C file, then the real fun begins!
Where *did* this *stuff* come from !?!?  Is this *really* C !?!?
Depending on the compiler you have, the situation may be better
or worse [and my guess is the situation is going to get worse
before it gets better -- as more advanced features are added to
the language.]

To analyse the intermediate C code, I typically do one of two
things 1) compile it and look at the assembly code generated
2) try to edit the "C" code generated down to something that
vaguely resembles what was originally programmed in C++.

Usually option 1) is more expedient, and the assembly code
is more readily understandable than the "C" code generated!
[Again, how bad the situation is depends on the C++ compiler you
have.]  Option 1) assumes you have a good optimizing C compiler.
If not, you need to get one.  C++ using C as an intermediate
representation is miserable without a good optimizing C compiler.
[cfront using gcc as a backend seems to be a good combination]

Option 2) can take an hour or two for a small C++ compilation.
I typically start by throwing away the part of the file 
generated by #includes.  Next I throw away #line statements.
Then I reverse encode variable names.  Next I try getting
rid of gratuitous (&glop)->part code, rewriting these
as glop.part.  Next I look at comma expressions, throwing
away trailing comma parts that don't have side effects,
and don't get assigned to.  I change the comma expressions
back to statements, rebalancing the parentheses as I
go.  Next, I get rid of the extra parentheses, and rename
temporaries generated by C++ from something like:
"__0013210321squigglesquawk" to "tmpx".  Then I get rid of
extraneous type conversions, and remove the struct thisandthat
required by C, and reverse encode method names to something
similar to their original names.  By this time I'm either
ready to give up; or I have something pretty close to 
vanilla-C.

So, the point being, even if you can get an intermediate "C"
file, analysing what a C++ compiler is doing is a royal pain
in the butt.

Still, in the absence of documentation on what C++ compilers
are doing, and why, this is the only real way to really learn the
C++ language, and its implementations, so I think its worth
the effort.