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