From: comeau@csanta.attmail.com (Greg Comeau)
Subject: Re:  Comeau C++
Originator: comeau@well.sf.ca.us
Reply-To: comeau@csanta.attmail.com (Greg Comeau)
Organization: Comeau Computing
Date: Tue, 13 Oct 1992 11:38:07 GMT

>In article <1537@igd.fhg.de>, john@igd.fhg.de (Werner John) writes:
>|> Hello everyone,
>|> 
>|> So SAS-C++ will come along with a C++ source level debugger, does it?
>|> Hmmm that triggers some more thoughts.  How do you debug C++ programs compiled
>|> with Comeau C++?  I think every one who does programming in C++ has seen
>|> the nasty names that are created by the front end as C-function names.
>|> I really hate to debug this kind of stuff.  printf, sorry, I should say
>|> cerr debugging is sometimes quite useful, but ablsolutely not state-of-
>|> the-art.  Is there a source level debugger for Comeau C++ available? 
>
>There are pluses and minuses here.  While the mangled names are difficult 
>to read, they do contain the class name and the method name.  Its not that
>hard to figure out which method is going to be called.  You also get the
>advantage of being able to pick your backend compiler.  

Our encoding mechanism is documented in full as far as I know.
For the most part so people are on the same wavelength, what we are
talking about is two-fold.  The nutshell of the 1st 1/2 half is just
taking the first letter of the name of the fundamental types that are
in the arguments.

   So foo(int) would be foo__Fi
      foo(void) would be foo__Fv
      foo(double) would be foo__Fd
      foo(int, double) would be foo__Fid

The nutshell of the 2nd 1/2 half is just taking the name of the
non-fundamental types that are in the arguments and uttering them
along with the length of their name:

   So foo(complex) would be foo__F7complex
      foo(blah) would be foo__F4blah
      foo(int, blah) would be foo__Fi4blah

Somewhat annoying, but something people appear to get used to
with little effort.  Also, generally all you want to know is that it is foo.
OTOH, I do appreciate that if it can be made invisible it should be
(and that is some of what we have done in the UNIX ports so far).

Picking the backend has its benefits too, but of course that it not
a debugger issue per se, but instead one of the benefits to generating
C code as our intermediate form.

>There are also some advantages to looking at the intermediate C code.  When 
>you look at a line of C code, you know basically what the assembly code 
>looks like.  It's not nearly so obvious with C++.  With overloaded 
>operators, you can have very simple statements that end up producing an 
>amazing amount of code.  

Yes, and no.  Yes in the sense that the more you know, the better you
alledgedly are.  Yes in the sense that you can see it if necessary and
tune things, etc.  No in the sense that you should not depend on it
from the perspective that even though it sometimes if helpful or revealing
to see the assembler code generated, your source code is still some HLL,
and that should be the program you are maintaining.

>These are the sorts of things 
>you might miss if you never looked at anything but the C++ code.

Just like these are the kinds of things that one would miss if one
never looked at the asm or object code from say a C compiler.  But
see the note above.

>So, there
>are advantages to having the intermediate C code.  Its nice that C++ hides
>a lot of the nitty gritty stuff, but it can make the code look deceptively
>simple.

Surely there is.  That is just one of them.  Others are that as a C
compiler is "everywhere", we are able to port Comeau C++ much easier
than other C++ compilers.  Furthermore, people are able to use of stuff
for things like embedded systems targets even though we do not have
a C++ compiler for the target CPU/et al in question.

- Greg
-- 
         Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418
                   Producers of Comeau C++ 3.0 With Templates
          Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421
	    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a