Re: Migrate from GCC 2.96 to GCC 3.0

[Joe Buck <jbuck at synopsys dot COM>]

> We understand that the GCC 2.96 is not a formal GCC release. Our problem
> is we have to use it in order to adapt to the support from system
> hardware and VxWorks, which will release their product developed on GCC
> 2.96. Our question is how much effort we need to migrate our GCC 2.96
> compiled code to GCC 3.0 or some other GNU versions.

For C code, there should be no issue.  For C++ code, there are significant
issues.

2.96-RH (the release that Red Hat called "2.96") still uses the old
libstdc++, not the new, standards-conformant libstdc++ shipped with 3.0.
In the new library, the standard library classes are in the std namespace,
and iostreams are templates (as the ISO C++ standard specifies).  In the
old library, the standard library classes are in the global namespace, and
iostreams are ordinary classes.

Despite this, it isn't all that bad to port.  The standard specifies
headers like <iostream>.  If you include <iostream.h> instead, then
you get directives to import the important symbols into the global
namespace (e.g. "using std::ostream"), so most old code will work.

The biggest gotcha in converting old code (whether for 2.95.x or "2.96")
is that it's no longer valid to say

class ostream;

because ostream is no longer a class (it is now a typedef).  The obvious
thing to do is to write

#include <iostream.h>

instead, but this slows down compilation.  Because of this the C++
standard provides the <iosfwd> header (for forward declarations of the
iostream typedefs).  So where you have

class ostream;

you could write

#include <iosfwd>
using std::ostream;

Finally, "2.96" isn't link-compatible with 3.0 even if no library classes
are used at the interfaces.

The using directives I show above are selective.  Another alternative
is "the sledgehammer" --

using namespace std;

This might be fine to get old programs to work, but I think it's better
practice to selectively import names.