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