home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11699 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  1.5 KB
  1. Xref: sparky comp.lang.c++:11699 gnu.gcc.help:1801 gnu.g++.help:1054
  2. Path: sparky!uunet!decwrl!bu.edu!ai-lab!ai.mit.edu!gnulists
  3. From: martin@oahu.cs.ucla.edu (david l. martin)
  4. Newsgroups: comp.lang.c++,gnu.gcc.help,gnu.g++.help
  5. Subject: porting to g++ (from other "dialects")
  6. Message-ID: <gnusenet1992Jul28.160935.11839@cs.ucla.edu>
  7. Date: 28 Jul 92 16:09:35 GMT
  8. Followup-To: poster
  9. Organization: UCLA Computer Science Department
  10. Lines: 21
  11. Approved: info-gnu@prep.ai.mit.edu
  12. To: gnu-gcc-announce@uunet.uu.net
  13. Originator: martin@oahu.cs.ucla.edu
  14. Nntp-Posting-Host: oahu.cs.ucla.edu
  15.  
  16. I am involved in a project in which we need to be able to use g++
  17. (that is, the g++ component of the latest version of gcc) to compile*
  18. existing source code which was developed for a variety of other
  19. leading C++ compilers - including CFRONT, Borland, Zortech, and
  20. Sabre.  I know there are still incompatibilities between g++ and
  21. the other dialects, but I need to know just how bad they are.  For
  22. example, if I take an average body of CFRONT-compilable code, what
  23. percentage of it might be rejected by g++, in the sense of causing
  24. a fatal error?
  25.  
  26. I would greatly appreciate the benefit of experience from anyone
  27. who's ported to g++ from a different compiler.
  28.  
  29. (*To be more precise, I won't actually be generating executables from
  30. the source code.  I'll be using g++ as a front-end to analyze
  31. existing source code and produce an intermediate representation which 
  32. describes it - essentially an attributed syntax tree.)
  33.  
  34. Thanks!
  35.  
  36. - Dave Martin
  37.