jmarvin@.oracle.com (John W. Marvin) (04/12/91)
I assume there is no C++ debugger w/ Comeau? Where is SaberC++ when you need it 8*)! Will the SAS C++ compiler have a debugger? ******************************************************************* * John W. S. Marvin * There are times when the wolves * * Oracle Multimedia Development * are silent, and the moon is * * jmarvin@us.oracle.com * howling... * *******************************************************************
comeau@ditka.Chicago.COM (Greg Comeau) (04/12/91)
In article <1991Apr10.051104.25326@menudo.uh.edu> tron1@tronsbox.xei.com (Kenneth Jamieson) writes: >This is a good product on the whole. I would recommend it to anyone who >has an interest or need for C++. The compiler is mature and stable, and >well tested. The driver needs major work but that is on the way and NOT >fatal. Out of a score of 100 this is an 80, and worth the $250. > >(c) 1991 Kenneth Jamieson I am posting 2 responses to your review: one dealing with technical things and another dealing with everything else. This is the everything else response ;-). >Well, as anyone who has worked with C++ in any form knows, this >language and the Amiga were meant for each other. The Amiga's GUI interface >is very clean to start with in most cases, and all GUI's are a perfect >candidate for the object features in C++. We think so. In fact, we were badgered for a while from a few people about doing the port for over 2 years. Eventually we committed to doing the port, but it wasn't until we actually got to use an Amiga did we realize how true this was.. and is. >and Amiga programmers are starting to hear the term [C++] more and more. All "walks of life" are. C++ is past the research stage and has been proven to be capable of tackling what it says it can. And of course, the AmigaDOS phenomenon actually begs for it, given the composition of its abstract functionality. >Comeau Computing 91-34 120th St. Richmond Hill, NY 11418 >(718)-945-0009 BIX: comeau Compuserve: 72331,3421 >Usenet: uunet!attmail!csanta!c++ A few notes on communicating with us: o We also have fax access via 718-441-2310 o On Bix, one can either 'mail to comeau' or 'j comeau' as we've a BIX vendor support conference. [It is also worth noting that BIX has an excellent C and C++ conferences (like newsgroups) called c.language and c.plus.plus respectively. I am the moderator of those conf's and they contain much C and C++ messaging of a good quality and nature with a low bandwith of noise and flack. There is also a host of expert in each conference (for instance, Stroustrup monitors c.plus.plus at least daily -- not this is not a recommendation to bombard him with messages and e-mail, just a example of what's there).] o On Compuserve, we can be reached directly via 72331,3421 or "hanging around" in various other areas including AMIGATECH's C language subarea ('go amigatech'). o uunet!attmail!csanta!c++ That should be attmail.com!csanta!c++ >The company is nice, and UPS Blue shipping is free. COD or prepay check >are needed for ordering. We also offer free technical support. BTW, it's also worth noting that we now also accept VISA, MasterCard, Discover Card, JCB Cards, Diner's Club International Cards, and Carte Blanche (sorry, no AMEX at the moment) >The technical support is fantastic Thanks! >when I needed details on the como.rexx driver, they listened well to >my suggestions, and kept me informed about my order status. Without customers, we wouldn't particularly have a product. Not listening to them or not getting back to them would only signify inevitable suicide. - 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
comeau@ditka.Chicago.COM (Greg Comeau) (04/12/91)
In article <1991Apr10.051104.25326@menudo.uh.edu> tron1@tronsbox.xei.com (Kenneth Jamieson) writes: >This is a good product on the whole. I would recommend it to anyone who >has an interest or need for C++. The compiler is mature and stable, and >well tested. The driver needs major work but that is on the way and NOT >fatal. Out of a score of 100 this is an 80, and worth the $250. > >(c) 1991 Kenneth Jamieson I am posting 2 responses to your review: one dealing with technical things and another dealing with everything else. This is the technical response. >The product installs in a painless manner, and I gather the >Install program would have made it easier. Yes, it would have! >5) Run the "include" program. You have to do this once. Comeau does NOT >distribute a full set of header files. This program will take your existing >C header files and "C++"-ize them. It's hard to tell whether you consider this good or bad! We think it good as our premise is that since we are requiring that you have a C compiler, and since each C compiler is slightly different, if we literally use what the C vendor supplies, little, if any, idiosyncrasies will crop up. Once 'include' is run, that's it, and you never need to worry about it until you upgrade and/or change your C compiler. Plus the C++ header and C headers can co-exist with no problem. >The "como" command is the hub of the compiler. Those using C++ >can equate this to a "CC". And there is problem number one. It doesn't act >ANYTHING like CC. This will make it difficult for anyone who is new from the >UNIX world. > >In addition, "como" is just not good enough to do real production >work with in my opinion. It is a good example of Arexx programming >though and easy to modify so this can be overcome. I think both those statements are stronger than that actual situation is. Nevertheless, como.rexx *does* need additional functionality. Furthermore, you are entitled to have your own opinion on that matter and I will (1) both respect that and (2) consider that it outweighs my own viewpoint. >The problems are ... All the problems are being addressed and should be solved in the (free) upgrade. Our plans are to have an upgrade come out this month and perhaps another again next month if it is needed as this is a new product and will have newness/overlooked quirks. The upgrade this month will also contain a bunch of tiny other fixes as well as a new version of the compiler itself even though the compiler is just about as solid as a rock. >There are by the way, no Amiga specific classes in the >compiler. This is straight C++. You can use the Amiga with the normal C >calls and interface, or write your own class library for it. That is correct. Our thinking here was that we could have gone all out this release, but that would have only resulted in a broken compiler, broken libraries, and broken tools. This way we spent the time and effort upfront on what we consider the focus of the product, the compiler itself. Now with that mostly out of the way and current feedback being addressed, we can move into the next phases and deal with libraries and tools and possible compiler extensions. All in all, I think your review was responsible and fair both in the good and bad things currently in Comeau C++. I would like to thank you for taking the time to inform the Amiga community about it as well as choosing to undertake the task. -- 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
tron1@tronsbox.xei.com (Kenneth Jamieson) (04/13/91)
In article <1991Apr12.001715.19397@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >I assume there is no C++ debugger w/ Comeau? Where is SaberC++ >when you need it 8*)! > Better -- I could live with a Turbo C++... 2.0, integreted editor/debugger, good classes, and 99$! >Will the SAS C++ compiler have a debugger? > When will it ever show up ? -- ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======= = "I know how you feel, you don't know if you want to hit me or kiss me - = = --- I get a lot of that." Madonna as Breathless Mahoney (Dick Tracy) = =========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 =================== = NONE of the opinions represented here are endorsed by anybody. = === The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
jac@gandalf.llnl.gov (James A. Crotinger) (04/13/91)
comeau@ditka.Chicago.COM (Greg Comeau) writes: > we now also accept VISA, MasterCard, Discover Card, JCB Cards, Diner's Club > International Cards, and Carte Blanche (sorry, no AMEX at the moment) I see the making of a VISA commercial here. 8-). > - Greg > -- -- ----------------------------------------------------------------------------- James A. Crotinger Lawrence Livermore Natl Lab // The above views jac@moonshine.llnl.gov P.O. Box 808; L-630 \\ // are mine and are not (415) 422-0259 Livermore CA 94550 \\/ necessarily those of LLNL
tron1@tronsbox.xei.com (Kenneth Jamieson) (04/14/91)
In article <36748@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: > >I am posting 2 responses to your review: one dealing with technical >things and another dealing with everything else. This is the technical >response. > >>5) Run the "include" program. You have to do this once. Comeau does NOT >>distribute a full set of header files. This program will take your existing >>C header files and "C++"-ize them. > >It's hard to tell whether you consider this good or bad! We think it Oh! I like it! Besides, I can use that program on my own include files as well I assume. It is much better than you having to ship updates every time SAS does. >Nevertheless, como.rexx *does* need additional functionality. Furthermore, >you are entitled to have your own opinion on that matter and I will >(1) both respect that and (2) consider that it outweighs my own viewpoint. Thank you! I appreciate it. >All in all, I think your review was responsible and fair both in the good >and bad things currently in Comeau C++. I would like to thank you for >taking the time to inform the Amiga community about it as well as choosing >to undertake the task. > >-- Greg Thanks! -- ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======= = "I know how you feel, you don't know if you want to hit me or kiss me - = = --- I get a lot of that." Madonna as Breathless Mahoney (Dick Tracy) = =========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 =================== = NONE of the opinions represented here are endorsed by anybody. = === The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
comeau@ditka.Chicago.COM (Greg Comeau) (04/15/91)
In article <1991Apr12.001715.19397@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >I assume there is no C++ debugger w/ Comeau? That is currently correct, however it is worth noting that as we currently are telling you to do something like "buy a C compiler too", the result is that you will have a C debugger like CPR and that works fine. -- 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
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/16/91)
In article <36748@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <1991Apr10.051104.25326@menudo.uh.edu> tron1@tronsbox.xei.com (Kenneth Jamieson) writes: > >>5) Run the "include" program. You have to do this once. Comeau does NOT >>distribute a full set of header files. This program will take your existing >>C header files and "C++"-ize them. > >It's hard to tell whether you consider this good or bad! We think it >good as our premise is that since we are requiring that you have a C >compiler, and since each C compiler is slightly different, if we literally >use what the C vendor supplies, little, if any, idiosyncrasies will crop >up. Once 'include' is run, that's it, and you never need to worry about it >until you upgrade and/or change your C compiler. Plus the C++ header and >C headers can co-exist with no problem. I am confused. Does the C++ compiler rewrite your C++ source code into plain'ol C and use your old 'C' compiler to compile it or is it that it was too costly (whatever) to include your own includes? I don't understand how any idiosyncrasies could crop up if your old compiler is not being used. > >-- 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
tron1@tronsbox.xei.com (Kenneth Jamieson) (04/16/91)
In article <1991Apr15.170545.14190@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > I am confused. Does the C++ compiler rewrite your C++ source code into >plain'ol C and use your old 'C' compiler to compile it or is it that it was too >costly (whatever) to include your own includes? I don't understand how any >idiosyncrasies could crop up if your old compiler is not being used. The "official" AT&T Cfront program is what defines the C++ standard. That program takes C++ and generates C. -- ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======= = "I know how you feel, you don't know if you want to hit me or kiss me - = = --- I get a lot of that." Madonna as Breathless Mahoney (Dick Tracy) = =========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 =================== = NONE of the opinions represented here are endorsed by anybody. = === The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
mr3@ukc.ac.uk (M.Rizzo) (04/16/91)
In article <36851@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <1991Apr12.001715.19397@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >>I assume there is no C++ debugger w/ Comeau? > >That is currently correct, however it is worth noting that as we currently >are telling you to do something like "buy a C compiler too", the result >is that you will have a C debugger like CPR and that works fine. I can understand that CPR will work with C++ code and will try to do its best - but I can't see how it will be able to understand the "this" pointer. The GNU debugger gdb required a number of extensions to work properly with GNU g++ - I think CPR will need a few as well. Another problem is that member function names of the form "class::function" get translated to some other C function name internally - I don't know for sure but I expect this is the case with Comeau C++ (that's how its done on GNU and Zortech). Michael Rizzo
baker@wbc.enet.dec.com (04/17/91)
>>I assume there is no C++ debugger w/ Comeau? >That is currently correct, however it is worth noting that as we currently >are telling you to do something like "buy a C compiler too", the result >is that you will have a C debugger like CPR and that works fine. Yes, but... Using CPR would allow you to look at the C which resulted from compiling the C++ source code. It would not give you the ability to debug at the C++ source level. This is a much-less-than-optimal solution. *********************************************************** * Art Baker | "Perscriptio in manibus * * baker@wbc.enet.dec.com | tabellariorum est." * * PLINK: A*BAKER | * ***********************************************************
comeau@ditka.Chicago.COM (Greg Comeau) (04/17/91)
In article <1540@tronsbox.xei.com> tron1@tronsbox.xei.com (Kenneth Jamieson) writes: >In article <36748@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >>>5) Run the "include" program. You have to do this once. Comeau does NOT >>>distribute a full set of header files. This program will take your existing >>>C header files and "C++"-ize them. >>It's hard to tell whether you consider this good or bad! We think it > Oh! I like it! Besides, I can use that program on my own >include files as well I assume. It is much better than you having to >ship updates every time SAS does. Exactly! Furthermore, when we add support for Aztec and DICE back-end, it becomes a piece of cake. 30 second, a doing, it's finished! We took this same approach under MS-DOS and it appears to be effective. - 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
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/18/91)
In article <36963@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <1540@tronsbox.xei.com> tron1@tronsbox.xei.com (Kenneth Jamieson) writes: >>In article <36748@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >>>>5) Run the "include" program. You have to do this once. Comeau does NOT >>>>distribute a full set of header files. This program will take your existing >>>>C header files and "C++"-ize them. >>>It's hard to tell whether you consider this good or bad! We think it >> Oh! I like it! Besides, I can use that program on my own >>include files as well I assume. It is much better than you having to >>ship updates every time SAS does. > Since this C++ compiler rewrites your C++ into plain'ol C, does it do a good job? Say compared to if a human performed the translation manually.
comeau@ditka.Chicago.COM (Greg Comeau) (04/18/91)
In article <1991Apr15.170545.14190@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >In article <36748@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >>since we are requiring that you have a C >>compiler, and since each C compiler is slightly different, if we literally > > I am confused. Does the C++ compiler rewrite your C++ source code into >plain'ol C and use your old 'C' compiler to compile it or is it that it was too >costly (whatever) to include your own includes? I don't understand how any >idiosyncrasies could crop up if your old compiler is not being used. > Like it says, we currently require you to have a C compiler. Comeau C++ DOES NOT rewrite your C++ source into plain'ol C though. It does full compilation (syntax, semantic, error, type, etc checking, analysis, etc) and decides in it's code generation phase to output C based on it internal compiler trees (which look nothing like C or C++ BTW). So, since the C has the includes already, it would be redundant for us to re-supply them. Only in cases where things have "gone wrong" will we supply an include file and/or a patch to one. - 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
comeau@ditka.Chicago.COM (Greg Comeau) (04/18/91)
In article <1544@tronsbox.xei.com> tron1@tronsbox.xei.com (Kenneth Jamieson) writes: >In article <1991Apr15.170545.14190@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >> I am confused. Does the C++ compiler rewrite your C++ source code into >>plain'ol C and use your old 'C' compiler to compile it or is it that it was too > > The "official" AT&T Cfront program is what defines the C++ >standard. That program takes C++ and generates C. Exactly. But it does not pre-* it (pre-process, pre-compile, etc). It does total full translation. The fact that it generates C in no way implies anything less is occurring. For instance, we also sell a UNIX Bourne Shell Compiler, which generates C as its object code, and that certainly is not a one-to-one mapping. Neither is it in the case of C++. In fact, by the time it gets to output the C, the trees it generates look nothing like C or C++. Also, those trees would have no inherent difference to the trees in a native code generating compiler. In fact, that is so much so that that has been a direction we've wanted to take Comeau C++ in for the longest time since the portableness of the compiler has been so successful. To all: sorry if it sounds like I'm coming on strong here in these past few messages, but some myths float around about C++, especially when it hits a new platform, and I'm just trying to halt them in their tracks before they get worse. - 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
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (04/19/91)
In article <37044@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <1991Apr15.170545.14190@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >>In article <36748@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >>>since we are requiring that you have a C >>>compiler, and since each C compiler is slightly different, if we literally >> >> I am confused. Does the C++ compiler rewrite your C++ source code into >>plain'ol C and use your old 'C' compiler to compile it or is it that it was too >>costly (whatever) to include your own includes? I don't understand how any >>idiosyncrasies could crop up if your old compiler is not being used. >> > >Like it says, we currently require you to have a C compiler. Comeau C++ >DOES NOT rewrite your C++ source into plain'ol C though. It does full >compilation (syntax, semantic, error, type, etc checking, analysis, etc) >and decides in it's code generation phase to output C based on it internal >compiler trees (which look nothing like C or C++ BTW). So, since the C has >the includes already, it would be redundant for us to re-supply them. > >Only in cases where things have "gone wrong" will we supply an include file >and/or a patch to one. > >- 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 You only require a C compiler, because it is bundled with the include files. What if a potential customer does not already have a C compiler and therefore no includes. This is not an impossible scenario. I guess as a recourse one could obtain the include files from CATS. I read earlier that your C++ compiler was selling for $250. That seems steep considering that it is incomplete. -jeff
jmarvin@.oracle.com (John W. Marvin) (04/19/91)
In article <7285@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >In article <36851@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >>In article <1991Apr12.001715.19397@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >>>I assume there is no C++ debugger w/ Comeau? >> >>That is currently correct, however it is worth noting that as we currently ^^^^^^^^^ >properly with GNU g++ - I think CPR will need a few as well. Another problem >is that member function names of the form "class::function" get translated >to some other C function name internally - I don't know for sure but I expect > All true. However, I do not want to debug C++ using a C debugger, anymore than I want to debug C using an assembly debugger. Sure, I might play with G++, but I will not spend money on a C++ system w/o a C++ debugger. Note: Greg said "currently correct." He may get my money yet! ******************************************************************* * John W. S. Marvin * There are times when the wolves * * Oracle Multimedia Development * are silent, and the moon is * * jmarvin@us.oracle.com * howling... * *******************************************************************
comeau@ditka.Chicago.COM (Greg Comeau) (04/20/91)
In article <1991Apr16.162304.28491@decuac.dec.com> baker@wbc.enet.dec.com writes: >CPR would allow you to look at the C which resulted from compiling the C++ >source code.It would not give you the ability to debug at the C++ source level Not so at all. Using CPR allows you to debug/look at the C++ source _*NOT*_ the intermediate C. - 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
comeau@ditka.Chicago.COM (Greg Comeau) (04/20/91)
In article <1991Apr17.174759.16250@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > Since this C++ compiler rewrites your C++ into plain'ol C, does it >do a good job? Say compared to if a human performed the translation manually. That is not quite the issue as the C code is not quite the way a human would do it in C ...remember that we code in some language for readability. Also, this is machine generated output not intended for human consumption just like the asm output of your C compiler is not necessarily intended for human consumption. This "not intention" does not mean the code is bad though. In any event, the C code emitted does not contain anything it doesn't need and the C compiler is still at liberty (and should) to optimize the code. From my discussion with other compiler writers as well as my own feelings, there is very little that say a direct native code compiler could do better, and when it can, it usually comes down to only another instruction (and yes, an extra instruction could be critical for an app, but certainly the difference between a translating compiler and a direct native code compiler has nothing to do with that). - 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
tron1@tronsbox.xei.com (Kenneth Jamieson) (04/20/91)
In article <36851@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <1991Apr12.001715.19397@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >>I assume there is no C++ debugger w/ Comeau? > >That is currently correct, however it is worth noting that as we currently >are telling you to do something like "buy a C compiler too", the result >is that you will have a C debugger like CPR and that works fine. I can understand that CPR will work with C++ code and will try to do its best - but I can't see how it will be able to understand the "this" pointer. The GNU debugger gdb required a number of extensions to work properly with GNU g++ - I think CPR will need a few as well. Another problem is that member function names of the form "class::function" get translated to some other C function name internally - I don't know for sure but I expect this is the case with Comeau C++ (that's how its done on GNU and Zortech). Michael Rizzo -- ========[ Xanadu Enterprises Inc. Amiga & Unix Software Development]======= = "I know how you feel, you don't know if you want to hit me or kiss me - = = --- I get a lot of that." Madonna as Breathless Mahoney (Dick Tracy) = =========== Ken Jamieson: uunet!tronsbox.xei.com!tron1 =================== = NONE of the opinions represented here are endorsed by anybody. = === The Romantic Encounters BBS 201-759-8450(PEP) / 201-759-8568(2400) ====
comeau@ditka.Chicago.COM (Greg Comeau) (04/22/91)
In article <7285@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >I can understand that CPR will work with C++ code and will try to do its >best - but I can't see how it will be able to understand the "this" >pointer. The GNU debugger gdb required a number of extensions to work >properly with GNU g++ - I think CPR will need a few as well. I don't see why. ``this'' is just a const pointer to the object being passed. Therefore a class member is just this->'d. What problem di g++/gcc have in this area? >Another problem >is that member function names of the form "class::function" get translated >to some other C function name internally - I don't know for sure but I expect >this is the case with Comeau C++ (that's how its done on GNU and Zortech). That is correct. We find that initial purchasers of Comeau C++ will sometimes call up about this, but often never call twice as they get used to it since C++ has many characteristics which diverts the energy normally spent in debugging into other areas of the programming cycle. Nevertheless, this is something that we spend time on solving with the ports of Comeau C++ we do. For instance, under UNIX we have something called CCsdb, which allows you to use to C++ names as is. - 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
comeau@ditka.Chicago.COM (Greg Comeau) (04/22/91)
In article <1991Apr18.174810.14120@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > You only require a C compiler, because it is bundled with the include >files. No, that is not correct. We require a C compiler because Comeau C++ is very portable. One functional aspect of this portability is that we generate C as our object code. So, the availablilty of the C compiler's include files is just one pleasant side-effect of this portability issue. - 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
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (04/22/91)
tron1@tronsbox.xei.com (Kenneth Jamieson) writes: > The "official" AT&T Cfront program is what defines the C++ >standard. That program takes C++ and generates C. > So then, the new lattice C++ (from what i've heard) will compile directly to object modules. this means then that the lattice compiler will not be standard? I've ALWAYS disliked the fact that with lattice you had to dis-assemble an object module to see the assembly as well. to me the perfect C++ would compile to C, then from C to assembly, and then assemble the assembly, of course allowing anywhere in between to stop and examine any stage. the Manx C compiler does this quite well, even embeds the C source into the assembly as comments if you like. Would anyone else like a C++ compiler to do this? UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
daveh@cbmvax.commodore.com (Dave Haynie) (04/23/91)
In article <1991Apr17.174759.16250@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > Since this C++ compiler rewrites your C++ into plain'ol C, does it >do a good job? Say compared to if a human performed the translation manually. When a C++ compiler translates C++ code into C, it is doing much the same thing that a C compiler does when it translates C into object code. Could you do a better job of translating C into assembler? I would think not, though a good assembler programmer can write somewhat more efficient code in assembler than a C programmer writes via a typical compiler. Given the extra complexities of the C++ language, even if you wanted to do a hand translation, and felt you could do better, it would take forever, and your head would eventually explode. I don't think you want to hand translate Modula2 or Ada into C, either, but it certainly could be done. -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy "That's me in the corner, that's me in the spotlight" -R.E.M.
comeau@ditka.Chicago.COM (Greg Comeau) (04/23/91)
In article <1991Apr18.203037.7171@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >In article <7285@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >>In article <36851@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >>>In article <1991Apr12.001715.19397@oracle.com> jmarvin@oracle.com (John W. Marvin) writes: >>>>I assume there is no C++ debugger w/ Comeau? >>> >>>That is currently correct, however it is worth noting that as we currently > ^^^^^^^^^ >All true. However, I do not want to debug C++ using a C debugger, >anymore than I want to debug C using an assembly debugger. It's not quite like that at all. Rememeber: C++ is a superset of C, therefore, most all things will be exactly the same. What your C debugger will be at a loss for will be intimate details on stuff like class relationships. We have discussed this with customers and although both they and us are working towards a resolution of the issue, in the interim, they have told us that in most cases, they are not using overwhelingly compilcated classes or not more that 2 levels of inheritance in most cases, and hence they do not consider the situation alarming or unusable, but instead just plain old annoying at times. They also follow up by mentiioning that they feel a few steps ahead of the game even after pros - cons. >Note: Greg said "currently correct." He may get my money yet! Take you time. But in the meantime, on a different subject, there is this here bridge.... ;-) - 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
GHGAQZ4@cc1.kuleuven.ac.be (04/23/91)
>So then, the new lattice C++ (from what i've heard) will compile directly to >object modules. this means then that the lattice compiler will not be >standard? I've ALWAYS disliked the fact that with lattice you had to >dis-assemble an object module to see the assembly as well. to me the perfect >C++ would compile to C, then from C to assembly, and then assemble the >assembly, of course allowing anywhere in between to stop and examine any >stage. the Manx C compiler does this quite well, even embeds the C source >into the assembly as comments if you like. Would anyone else like a C++ >compiler to do this? I hope Lattice is NEVER going to do that (except when they make it optional ofcourse) because this approach is slow (not that Lattice is very fast at this moment but it would be worse with compilation to assembly instead of object code). And there is still another reason that I don't want that : Lattice ASM is about the slowest assembler I've ever seen. If you'd had to assemble after each compile session your productivity level would go below zero I think. Jorrit Tyberghein
brian@babbage.csus.edu (Brian Witt) (04/23/91)
In article <20862@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >In article <1991Apr17.174759.16250@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: > >> Since this C++ compiler rewrites your C++ into plain'ol C, does it >>do a good job? Say compared to if a human performed the translation manually. > >When a C++ compiler translates C++ code into C, it is doing much the same thing >that a C compiler does when it translates C into object code. There are a few oddities of coercien that go on, behind the scenes. For the objective-C (TM) like translator I built, for each message invokation, the "outter most" addition the translator does it put a typecast on the function call. Using a lead in Dr. Cox's book, I typecast the function _msg() to a function that returns the required type. This is NOT typecasting the return value (which can cause a conversion to take place, ie int --> float). Function _msg() by default returns a pointer type. with this define: extern void *_msg( void *, SEL, ... ); For instance, the line: char *name = [bytestring name]; turns into: char *name = (*((char * (*)()) _msg))( bytestring ,(/* name */_ocSAnoname[9])) ) ); (_ocSAnoname[] holds method selectors. it's long, but it works! ) > Given the extra complexities of >the C++ language, even if you wanted to do a hand translation, and felt you >could do better, it would take forever, and your head would eventually explode. In my OCT system, I've found that a line length doubles when converted from objective-C (TM) into plain old "C". Since OCT using dynamic binding throughout, you have to jump to a helper function. With static binding (like that in C++), your milage may vary... >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy objective-C is a trademark of Stepstone, Inc. ---------------------------------------------------------------- brian witt | brian@babbage.ecs.csus.edu You are what you click | (and if you click it twice...) Not representing Cal State Sacramento, the ECS dept, or Iraq ---------------------------------------------------------------- -- ---------------------------------------------------------------- brian witt | brian@babbage.ecs.csus.edu You are what you click | (and if you click it twice...) Not representing Cal State Sacramento, the ECS dept, or Iraq
es1@cunixb.cc.columbia.edu (Ethan Solomita) (04/24/91)
In article <37303@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: > >Rememeber: C++ is a superset of C, therefore, most all things will >be exactly the same. What your C debugger will be at a loss for >will be intimate details on stuff like class relationships. We have >discussed this with customers and although both they and us are working >towards a resolution of the issue, in the interim, they have told us >that in most cases, they are not using overwhelingly compilcated >classes or not more that 2 levels of inheritance in most cases, >and hence they do not consider the situation alarming or unusable, >but instead just plain old annoying at times. They also follow up >by mentiioning that they feel a few steps ahead of the game even after >pros - cons. > Greg, I think there is a GAPING hole in the Amiga market for a good debugger. Perhaps I've just missed it, but I've never seen anything of the quality of gdb. If I want to evaluate an expression that is reasonably complicated, I have no fear that it will work in gdb. CPR only does the simplest of expressions. If you are looking for ideas, you should definitely consider writing a high-quality debugger, one that can work with C as well as C++ if you want to get into a larger and very desperate market. > >- 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 -- Ethan Q: How many Comp Sci majors does it take to change a lightbulb A: None. It's a hardware problem.
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (04/24/91)
GHGAQZ4@cc1.kuleuven.ac.be writes: >>So then, the new lattice C++ (from what i've heard) will compile directly to >>object modules. this means then that the lattice compiler will not be >>standard? I've ALWAYS disliked the fact that with lattice you had to >>dis-assemble an object module to see the assembly as well. to me the perfect >>C++ would compile to C, then from C to assembly, and then assemble the >>assembly, of course allowing anywhere in between to stop and examine any >>stage. the Manx C compiler does this quite well, even embeds the C source >>into the assembly as comments if you like. Would anyone else like a C++ >>compiler to do this? > >I hope Lattice is NEVER going to do that (except when they make it optional >ofcourse) because this approach is slow (not that Lattice is very fast at >this moment but it would be worse with compilation to assembly instead of >object code). And there is still another reason that I don't want that : >Lattice ASM is about the slowest assembler I've ever seen. If you'd had >to assemble after each compile session your productivity level would go >below zero I think. > > Jorrit Tyberghein Well, the Aztec compiler compiles to assembly first, and i find that it's FASTER than lattice compiling the same thing, so i don't think that argument holds.. .--------------------------------------------------------------------------. | UUCP: {amdahl!tcnet, crash}!orbit!pnet51!chucks | "I know he's come back | | ARPA: crash!orbit!pnet51!chucks@nosc.mil | from the dead, but do | | INET: chucks@pnet51.orb.mn.org | you really think he's | |-------------------------------------------------| moved back in?" | | Amiga programmer at large, employment options | Lou Diamond Philips in | | welcome, inquire within. | "The First Power". | `--------------------------------------------------------------------------'
jleonard@pica.army.mil (04/24/91)
In article <1991Apr23.183734.7950@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > > Greg, I think there is a GAPING hole in the Amiga market > for a good debugger. Perhaps I've just missed it, but I've never > seen anything of the quality of gdb. If I want to evaluate an > expression that is reasonably complicated, I have no fear that it > will work in gdb. CPR only does the simplest of expressions. > If you are looking for ideas, you should definitely > consider writing a high-quality debugger, one that can work with > C as well as C++ if you want to get into a larger and very > desperate market. > I heartily second this motion. Even codeview puts all the Amiga debuggers I've seen to shame. ___________________________________________________________________________ |Jeff Leonard Usenet: jleonard@pica.army.mil | | My strength is as the strength of ten because my code is pure. | ---------------------------------------------------------------------------
iwm@doc.ic.ac.uk (Ian Moor) (04/24/91)
In article <37123@ditka.Chicago.COM> comeau@ditka.Chicago.COM (Greg Comeau) writes:
. From my discussion with other compiler writers as
well as my own feelings, there is very little that say a direct native
code compiler could do better, and when it can, it usually comes down
One problem with using a fairly complex language as an intermediate code,
especially when the `backend' is error reporting. As a case in point,
I am evaluating a Modula-2 compiler for SPARC that produces C, I get an
error message from Sun's C compiler about an intermediate file: is it
a bug in the C compiler, or has the modula compiler generated incorrect C?
The intermediate code is not meant to be read, and I have to assume the
modula compiler is wrong, since GCC does not like the file either.
You may find with the different C compilers SAS/Lattice/PDC/DICE/GCC...
that one will work and the others not.
--
Ian W Moor
Internet: iwm@doc.ic.ac.uk
JANET: iwm@uk.ac.ic.doc
Department of Computing, Lecturer,n. One with his hand in your pocket,
Imperial College. his tongue in your ear, and his faith in your
180 Queensgate patience.
London SW7 UK. Ambrose Bierce.m0154@tnc.UUCP (GUY GARNETT) (04/25/91)
In article <20862@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >I don't think you want to hand translate Modula2 or Ada into C, either, but it >certainly could be done. >-- >Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" > {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy > "That's me in the corner, that's me in the spotlight" -R.E.M. This may be a "programmer's legend" rather than a true story, but I heard (from a usually reliable source) that in the beginning days of the Ada standard, there was an Air Force contract which required some software to be written in Ada. Unfortunately, there was no DOD-qualified compiler for the target hardware (as a matter of fact, there was no compiler at all). So, two contracts were let: one to write the software, and one to write a compiler. Unfortunately, the usual factors slowed down the compiler development, so no working compiler was available to compile and test the code. SO, the contractor in question hired a veritable army of assembly language programmers, and set them to work "compiling" the Ada software. I believe that the compiler was eventually finished (and qualified), but that first programming project was delivered with hand "compiled" code. Wildstar
davidm@uunet.UU.NET (David S. Masterson) (04/26/91)
>>>>> On 24 Apr 91 14:38:39 GMT, iwm@doc.ic.ac.uk (Ian Moor) said: Ian> In article <37123@ditka.Chicago.COM> comeau@ditka.Chicago.COM (Greg Ian> Comeau) writes: Greg> From my discussion with other compiler writers as well as my own Greg> feelings, there is very little that say a direct native code compiler Greg> could do better, and when it can, it usually comes down Ian> One problem with using a fairly complex language as an intermediate code, Ian> especially when the `backend' is error reporting. As a case in point, I Ian> am evaluating a Modula-2 compiler for SPARC that produces C, I get an Ian> error message from Sun's C compiler about an intermediate file: is it a Ian> bug in the C compiler, or has the modula compiler generated incorrect C? Ian> The intermediate code is not meant to be read, and I have to assume the Ian> modula compiler is wrong, since GCC does not like the file either. Ian> You may find with the different C compilers SAS/Lattice/PDC/DICE/GCC... Ian> that one will work and the others not. This seems to be a contentious issue. One the one hand, compiling into C code is seen as a means of making the compiler easier to port from system to system (ANSI-C is more standard than the various assembly codes for the various systems that run ANSI-C). The advantage is that the output of the compiler will be more useful across a wider range of systems, but the disadvantage is that there may be problems and inefficiences in the back-end C compiler that the front-end compiler can't take into account. On the other hand, compiling into the lower level code means greater efficiencies can be implemented into the compiled code and compilation should be faster (one pass instead of two). The advantage is integration and performance, the disadvantage is more difficulties in porting. Also, adopting the view that code should compile to (at least) assembly level begs the question (in the case of C++) why should the language remain ANSI-C compliant? -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
comeau@ditka.Chicago.COM (Greg Comeau) (04/26/91)
In article <4670@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >tron1@tronsbox.xei.com (Kenneth Jamieson) writes: >> The "official" AT&T Cfront program is what defines the C++ >>standard. That program takes C++ and generates C. >> >So then, the new lattice C++ (from what i've heard) will compile directly to >object modules. this means then that the lattice compiler will not be >standard? I've ALWAYS disliked the fact that with lattice you had to That is not being fair. There is no doubt that we haven't see the Lattice C++ yet, and there is no doubt that it is *not* based on cfront as we are. But that only leads to the conclusion that it won't be among the so-called standard compilers. But in say the MS-DOS world, Zortech and Borland are not standard in that sense either. But that does not imply they are not good compilers (disregarding that any spanking new compiler is going to have a good number of bugs). - 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
Lee_Robert_Willis@cup.portal.com (04/28/91)
Greg, I'm very curious about how and to what extent SAS's CPR can be used to debug Comeau's C++ code. (A debugger is a _big_ issue. I wasn't considering buying your compiler until you mentioned that C debuggers could be used) Could you post a file which contains some source code, and the compiled executable (compiled with debug) so those of us with debuggers could try it out for ourselves? Thanks, Lee Lee_Robert_Willis@cup.portal.com
comeau@ditka.Chicago.COM (Greg Comeau) (05/01/91)
In article <CIMSHOP!DAVIDM.91Apr25121712@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: >>>>>> On 24 Apr 91 14:38:39 GMT, iwm@doc.ic.ac.uk (Ian Moor) said: >Ian> One problem with using a fairly complex language as an intermediate code, >Ian> especially when the `backend' is error reporting. As a case in point, I >Ian> am evaluating a Modula-2 compiler for SPARC that produces C, I get an >Ian> error message from Sun's C compiler about an intermediate file: is it a >Ian> bug in the C compiler, or has the modula compiler generated incorrect C? I dunno. That's a hard one to call given the information you've provided. What I can tell you is that the number of times such a scenario has popped up its head with our compiler is almost non-existant and the users almost always were able to understand the problem. To be honest, I've had more problems of this sort in asm generating C compilers than in any other situation (and I've both written and used other "to C" compilers). >This seems to be a contentious issue. One the one hand, compiling into C code >is seen as a means of making the compiler easier to port from system to system >(ANSI-C is more standard than the various assembly codes for the various >systems that run ANSI-C). Right. To add a few points: we don't require an ANSI C compiler. A K&R compiler will work fine as well. Also, the issue of things like cross-compiling and embedded systems in gneral cannot be handled as smoothly any other way (that is portability of the compiler itself is not the only issue although that is important) >The advantage is that the output of the compiler >will be more useful across a wider range of systems, but the disadvantage is >that there may be problems and inefficiences in the back-end C compiler that >the front-end compiler can't take into account. True, but for the most part these problems are as non-existant as the sporadic problems of other mechanisms. It is practical to say that it's a non-issue. >Also, adopting the view that code should compile to >(at least) assembly level begs the question (in the case of C++) why should >the language remain ANSI-C compliant? C++ should *not* reamin ANSI-C compliant. (Although this by no means says that it should and will make tangental leaps off that track... only to say that even though C is a subset of C++, they are 2 different languages). - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ 2.1 Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
comeau@ditka.Chicago.COM (Greg Comeau) (05/01/91)
In article <41769@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes: >I'm very curious about how and to what extent SAS's CPR can be used >to debug Comeau's C++ code. (A debugger is a _big_ issue. I >wasn't considering buying your compiler until you mentioned that C >debuggers could be used) Line number and source file information is retained and that is simply accepted by the C compiler. There is no special trick involved. >Could you post a file which contains some source code, and the >compiled executable (compiled with debug) so those of us with >debuggers could try it out for ourselves? I don't see what that would accomplish. It is my understanding that others here on the net have Comeau C++ and they are not disputing what I am saying. Since information about the original C++ source file is retained, the debug information points to the C++ source (as in most of this compilation process, the .c is truly only as a medium). Since the debug information is also know to the debugger, doing, say, a single step, is not a problem. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ 2.1 Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
gefrank@sdrc.COM (Frank Glandorf) (05/02/91)
In article <37918@ditka.Chicago.COM>, comeau@ditka.Chicago.COM (Greg Comeau) writes: > In article <41769@cup.portal.com> Lee_Robert_Willis@cup.portal.com writes: > >I'm very curious about how and to what extent SAS's CPR can be used > >to debug Comeau's C++ code. (A debugger is a _big_ issue. I > >wasn't considering buying your compiler until you mentioned that C > >debuggers could be used) Source code debuggers are important. If the source code and target language are close then debugging the target language is not difficult. C source debuggers work well with translators like lex and yacc. However Ratfor is sufficiently different from FORTRAN that I have trouble debugging it. Debugging assembler from C source is not worth the effort for the applications that I develop. > Line number and source file information is retained and that is simply > accepted by the C compiler. There is no special trick involved. Hmm. Sounds like the "#line" directive. This is really more useful for diagnostic messages than source code debugging. > >Could you post a file which contains some source code,... > I don't see what that would accomplish. I too would like to see the generated C code. If the C++ source and generated C are close then I might buy Comeau C++ otherwise I'll wait for a C++ that has a source code debugger. > - Greg > -- > Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 > Producers of Comeau C++ 2.1 > Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 > Voice:718-945-0009 / Fax:718-441-2310 -Frank
mr3@ukc.ac.uk (M.Rizzo) (05/02/91)
In article <37228@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <7285@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >>I can understand that CPR will work with C++ code and will try to do its >>best - but I can't see how it will be able to understand the "this" >>pointer. The GNU debugger gdb required a number of extensions to work >>properly with GNU g++ - I think CPR will need a few as well. > >I don't see why. > >``this'' is just a const pointer to the object being passed. Therefore >a class member is just this->'d. What problem di g++/gcc have in this >area? Oops (no pun intended) silly me - you're right Greg. In fact gdb didn't have any problem with "this" at all. It was just a wrong impression that I had - I should've checked before I opened my big mouth. I deserve to be flamed ! However I do recall seeing somewhere (probably on some gnu newsgroup) that there were a number of areas where gdb was being improved to provide better support for g++ i.e. gdb always worked with g++, but not always in a friendly manner, one of the problems being name mangling (see below) which has been resolved in the latest version of gdb. Another had to do with better understanding of multiple inheritance (exactly how I'm not sure). >>Another problem >>is that member function names of the form "class::function" get translated >>to some other C function name internally - I don't know for sure but I expect >>this is the case with Comeau C++ (that's how its done on GNU and Zortech). > >That is correct. We find that initial purchasers of Comeau C++ will >sometimes call up about this, but often never call twice as they get >used to it since C++ has many characteristics which diverts the energy >normally spent in debugging into other areas of the programming cycle. >Nevertheless, this is something that we spend time on solving with the >ports of Comeau C++ we do. For instance, under UNIX we have something called >CCsdb, which allows you to use to C++ names as is. With older versions of GNU gdb there was a small utility g++filt which one could use to translate between C++ and mangled identifiers. Used with a mouse cut-and-paste-text-between-windows as provided by xterm this was very useful. I believe such a PD utility for cutting & pasting text between console windows is available for the Amiga so maybe an equivalent of g++filt would be nice ? >- Greg Mike Rizzo
comeau@ditka.Chicago.COM (Greg Comeau) (05/05/91)
In article <7482@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >With older versions of GNU gdb there was a small utility g++filt which >one could use to translate between C++ and mangled identifiers. Used >with a mouse cut-and-paste-text-between-windows as provided by xterm this >was very useful. I believe such a PD utility for cutting & pasting text >between console windows is available for the Amiga so maybe an equivalent >of g++filt would be nice ? Comeau C++ comes with a utility we call c++filt, c++filt.CC, or comofilt depending upon the port (don't ask we why haven't standardized the name please) that supports just such a demangling capability. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ 2.1 Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310
mr3@ukc.ac.uk (M.Rizzo) (05/06/91)
In article <38213@ditka.Chicago.COM> comeau@csanta.attmail.com (Greg Comeau) writes: >In article <7482@harrier.ukc.ac.uk> mr3@ukc.ac.uk (M.Rizzo) writes: >>With older versions of GNU gdb there was a small utility g++filt ... > >Comeau C++ comes with a utility we call c++filt, c++filt.CC, or >comofilt depending upon the port (don't ask we why haven't standardized >the name please) that supports just such a demangling capability. Great stuff Greg! Why haven't you standardized the ... OOPS ! Sorry :-) A few days back I mentioned GNU gdb problems with g++. Here's one of them - it can't cast pointers properly with multiple inheritance (which may require that the value of the pointer be changed as defined in ARM pg 221). The following example demonstrates the problem class A { int a; }; class B { int b; }; class C : public A, public B { }; main() { C* pc = new C; B* pb = pc; // Implicit conversion here - add delta(B) } (gdb) br 10 Reading in symbols for demo.C...done. Breakpoint 1 at 0x22e4: file demo.C, line 10. (gdb) run Starting program: /usr/nfs/nutmeg/d1/users/mr3/a.out Bpt 1, main () (demo.C line 10) 10 } (gdb) print pc ::1 = (struct C *) 0x6d50 (gdb) print pb ::2 = (B *) 0x6d54 | Implicit cast causes 4 bytes to be added (gdb) print (B *) pc ::3 = (B *) 0x6d50 | Wrong ! Should be 0x6d54 as in ::2 above Although I haven't used CodeProbe much (and the last time I used it was ages ago) it should have the same problem debugging C++ code. >- Greg Michael Rizzo