Porting programs from other compilers to g++
============================================

   "I have a program that runs on <some other C++ compiler>, and I want
to get it running under g++.  Is there anything I should watch out for?"

   Note that g++ supports many of the newer keywords that have recently
been added to the language.  Your other C++ compiler may not support
them, so you may need to rename variables and members that conflict
with these keywords.

   There are two other reasons why a program that worked under one
compiler might fail under another: your program may depend on the order
of evaluation of side effects in an expression, or it may depend on the
lifetime of a temporary (you may be assuming that a temporary object
"lives" longer than the standard guarantees).  As an example of the
first:

     void func(int,int);
     
     int i = 3;
     func(i++,i++);

   Novice programmers think that the increments will be evaluated in
strict left-to-right order.  Neither C nor C++ guarantees this; the
second increment might happen first, for example.  func might get 3,4,
or it might get 4,3.

   The second problem often happens with classes like the libg++ String
class.  Let's say I have

     String func1();
     void func2(const char*);

   and I say

     func2(func1());

   because I know that class String has an "operator const char*".  So
what really happens is

     func2(func1().convert());

   where I'm pretending I have a convert() method that is the same as
the cast.  This is unsafe in g++ versions before 2.6.0, because the
temporary String object may be deleted after its last use (the call to
the conversion function), leaving the pointer pointing to garbage, so by
the time func2 is called, it gets an invalid argument.

   Both the cfront and the old g++ behaviors are legal according to the
ARM, but the powers that be have decided that compiler writers were
given too much freedom here.

   The ANSI C++ committee has now come to a resolution of the lifetime
of temporaries problem: they specify that temporaries should be deleted
at end-of-statement (and at a couple of other points).  This means that
g++ versions before 2.6.0 now delete temporaries too early, and cfront
deletes temporaries too late.  As of version 2.6.0, g++ does things
according to the new standard.

   For now, the safe way to write such code is to give the temporary a
name, which forces it to live until the end of the scope of the name.
For example:

     String& tmp = func1();
     func2(tmp);

   Finally, like all compilers (but especially C++ compilers, it seems),
g++ has bugs, and you may have tweaked one.  If so, please file a bug
report (after checking the above issues).