Newsgroups: comp.sys.amiga.programmer
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!news.cs.indiana.edu!msi.umn.edu!cs.umn.edu!dege
From: dege@cs.umn.edu (Dege Jeffrey Charles)
Subject: Re: OOP (was Re: Assembly Language & Programming)
Message-ID: <1991Apr20.125305.16254@cs.umn.edu>
Organization: University of Minnesota, Minneapolis, CSci dept.
References: <colin_fox.3793@outbound.wimsey.bc.ca> 	<NV89-NUN.91Apr16020559@dront.nada.kth.se> <37046@ditka.Chicago.COM> <CIMSHOP!DAVIDM.91Apr19131513@uunet.UU.NET>
Distribution: comp
Date: Sat, 20 Apr 91 12:53:05 GMT
Lines: 23

In <CIMSHOP!DAVIDM.91Apr19131513@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

>>>>>> On 18 Apr 91 15:25:05 GMT, comeau@ditka.Chicago.COM (Greg Comeau) said:

>On that different issue, though, from what I've seen, there are generally two
>reasons that a C++ to object file compiler is preferred over a C++ to C
>compiler.   I'd like your comments on the two:

>1.  Optimization.  ...

>2.  Debugger support.  ...

 
   And here I thought the biggest gain would be in compile time.  I see no
fundamental reason why a C++->C translator would produce poorer code than
a C++->object compiler.  I also see no fundamental reason why a C++->C
translator could not be used in a source-level debugger (It's all a matter
of where the debugging info gets put and who puts it there.)  The increased
compile time involved in scanning and parsing the code twice, though, cannot
be removed.   (I know, so buy a faster machine... ;)
 
---------------------

