home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / lang / cplus / 11687 < prev    next >
Encoding:
Internet Message Format  |  1992-07-28  |  2.1 KB

  1. Xref: sparky comp.lang.c++:11687 gnu.g++.help:1053
  2. Path: sparky!uunet!cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!forney.berkeley.edu!jbuck
  3. From: jbuck@forney.berkeley.edu (Joe Buck)
  4. Newsgroups: comp.lang.c++,gnu.g++.help
  5. Subject: Re: porting to g++ (from other "dialects")
  6. Date: 28 Jul 1992 20:16:25 GMT
  7. Organization: U. C. Berkeley
  8. Lines: 42
  9. Message-ID: <1549upINN876@agate.berkeley.edu>
  10. References: <1992Jul28.160935.11839@cs.ucla.edu>
  11. NNTP-Posting-Host: forney.berkeley.edu
  12.  
  13. In article <1992Jul28.160935.11839@cs.ucla.edu> martin@oahu.cs.ucla.edu
  14. (david l. martin) asks about portability problems encountered when porting
  15. code that compiles under cfront-based and other compilers to g++.
  16.  
  17. I am writing here about g++ version 2.2.2.  At this time, the major
  18. language incompatibilities are as follows:
  19.  
  20. 1.  The "placement" form of operator new.  The ARM specifies that you
  21. write
  22.  
  23.     new (address) Foo
  24.  
  25. and g++ requires
  26.  
  27.     new { address } Foo
  28.  
  29. This incompatibility has already been fixed and I believe that version
  30. 2.3, when released will support the ARM syntax.  This is the only
  31. significant divergence between g++ and the ARM at this point, other
  32. than exceptions which cfront doesn't have either.
  33.  
  34. 2.  The template implementation is still buggy, but it's been improving
  35. rapidly (2.2.2 is much better than 2.1).  g++ doesn't implement the cfront
  36. hack that lets you declare template functions in Foo.h and define them in
  37. Foo.c, and then do a hidden #include of Foo.c so everything will work.  If
  38. you do this in g++ you'll need to #include "Foo.c".
  39.  
  40. 3.  g++ used to have trouble with some complicated declarations
  41. (pointers to arrays of functions, etc) if you didn't use typedefs.
  42. I think these have been fixed.
  43.  
  44. 4.  Lifetime of temporaries.  cfront-based compilers don't call
  45. destructors on temporaries until the end of the enclosing block;
  46. g++ destroys them earlier.  The g++ behavior is legal according to the
  47. ARM, but cfront-based programs often rely on the extended lifetime
  48. of temporaries that cfront provides.  This may cause some problems,
  49. but the bugs aren't in g++ but in the unportable code.
  50.  
  51.  
  52.  
  53. --
  54. Joe Buck    jbuck@ohm.berkeley.edu
  55.