Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!lll-winken!unixhub!ditka!comeau From: comeau@ditka.Chicago.COM (Greg Comeau) Newsgroups: comp.sys.amiga.programmer Subject: Re: OOP (was Re: Assembly Language & Programming) Message-ID: <37301@ditka.Chicago.COM> Date: 23 Apr 91 05:04:07 GMT References: <37046@ditka.Chicago.COM> Sender: comeau@ditka.Chicago.COM (Greg Comeau) Reply-To: comeau@csanta.attmail.com (Greg Comeau) Distribution: comp Organization: Comeau Computing Lines: 58 In article cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 18 Apr 91 15:25:05 GMT, comeau@ditka.Chicago.COM (Greg Comeau) said: > >Greg> In article >Greg> nv89-nun@dront.nada.kth.se (Nicklas Ungman) writes: > >Nicklas> I also hope for better compilers in the future (many C++ compilers >Nicklas> are actually pre-compilers) > >Greg> You imply translating compilers (not pre-compilers) != better compiler. >Greg> The truth of the matter is that something like AT&T cfront, which Comeau >Greg> C++, is based on, is the most robust C++ compiler technology around. >Greg> And it's up-to-date too. I don't want to sound rude, but I don't see >Greg> the merit in that analogy. If you meant that you want to see a nice C++ >Greg> environment, then, yes, I drool for it myself, but I think that a >Greg> different issue than what you mentioned. > >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: Sure, no problem. >1. Optimization. C compilers *may* not have the knowledge to optimize out >some of the things a C++ compiler might leave lying around (outlined >inlines?). This is one of the reasons for NewCode Technologies CBACK program. As I believe I've mentioned here before, the issue of optimization is not a thing that in inherently a problem with generating C object code vs native object code. Either way has it's nuances as well as quirks in implementation. On average: the difference is not noticable across a series of applications. As to CBACK, yes, that has the potential for improving things (and we are currently in the process of evaluating it's usefulness), nevertheless, the significance of it is just as strong as an extra step or two of optimization of C code that is only done with an extra command line switch of two. Hence, all we've got in the same C situation in C++, regardless of whether C object code is being generated or direct object code is being generated. >2. Debugger support. Debugging translated C++ code is very difficult because >of name mangling and (often) lack of C++ source (the debugger shows C code). Again, there is nothing inherent in C++ prohibiting debugging (again, whether a C object code generator or a direct object code generator is being used). The lack of C++ source has never been a problem in a single port of Comeau C++ we've done and we've done quite a number at this point. I have heard of other implementations suffering this fate, and without trying to be rude, those vendors obviously did not know what was going on and/or didn't care and/or something. As to name mangling, I addresses this in another message a day or two ago (I will readdress it if it needs to be). - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310