|
|
In UDK C++, the C++ Standard library libC is by default a dynamic library rather than an archive. Normally this will have no visible effect on applications. However, the one difference is that a dynamic library's static initializations (including constructions) are always done for every object in the library needing them, whether or not that object is referenced in the application.
In the case of libC, this means that the cin, cout, and cerr objects are always initialized. This is done using the global placement new facility. If your application has replaced the global placement new with its own version, just be sure it will execute correctly during libC initialization.
If you are unsure whether this characteristic of libC is causing a difference in your application, link with the CC -dn option and see whether the behavior changes.
This only affects UnixWare 2.x source code. In the UDK C++ compilation system, the Standard Components classes have all been put into the namespace SCO_SC. This will prevent the frequent name collisions that Standard Components tends to encounter (e.g. class String with the String name in the X11 headers). However it will cause existing application code that uses Standard Components to not compile.
The best solution is to modify the application code to reference the namespace directly, either with explicit qualification, namespace using declarations, or namespace using directives. But as a shorter-term transitional measure, compiling with the -DUSING_SCO_SC compiler option will cause the Standard Components headers to automatically insert namespace using directives where necessary and will allow existing code to compile unmodified.
The UDK CC command is completely different from the OpenServer CC command. Most importantly, UDK CC treats a .c file as C++ code and invokes the C++ compiler, while OpenServer CC treats it as C code and invokes the C compiler. In addition, a number of the options are different between the two commands. OpenServer C++ makefiles should be examined carefully before using them with the UDK compilers; chances are some modifications will be necessary.
The UDK CC command has a couple of slight incompatibilities with the UnixWare 2.x CC command: the precedence of the -g and -O options is reversed, and the -o option can rename .i, .s, and .o files in addition to a.out files.
Binary compatibility here refers only to keeping the same C++ ABI. Even when the ABI stays the same, however, C++ still suffers from "release-to-release binary compatibility" problems. This happens when the private part of a class implementation changes, but it affects the class object layout such that all clients of the class have to be recompiled. (By comparison, C and Java do not suffer from this problem.)
The CC -Xo compatibility option is also useful in porting C++ code that comes from some other place, but was built with a Cfront-based compiler. Again, it should only be used as a transitional tool.
For code that comes from some other place but was not built with a Cfront-based compiler, there is no easy solution. Every recent C++ compiler incorporates some of the new ANSI/ISO features, but they incorporate them in different orders and against different versions of the draft standard. Fortunately, in another year or three this situation should stabilize and all C++ compilers will get on the same page.