|
|
For existing OpenServer-built code, there is a CC -Xo compatibility option that provides Cfront source compatibility. But this also enables Cfront bug tolerance, ancient anachronisms, and the like. It also isn't perfect -- there are some Cfrontisms that it won't detect or accept.
So it's only intended as a transitional tool to help you in converting your code in stages to the modern dialect of C++ that will be accepted by the UDK C++ compiler. It should not be used on a permanent basis; the only realistic way to deal with the evolving C++ language is to change your code!
Here's an example. Look at the following code:
src.C:
template <class T> class A { int m, n; int explicit; public: void f(); T g(); };template <class T> void A<T>::f() { for (int i = 0; i < 10; i++) n += i; for (i = 0; i < 10; i++) m += i; }
char A<char>::g() { return 'a'; }
int main() { A<int> a; a.f(); }
It compiles under the OpenServer C++ compiler:
non-udk-osr5-machine: CC src.C non-udk-osr5-machine:
But it gets all sorts of error messages under the UDK C++ compiler:
udk-machine: CC src.C "src.C", line 4: error: "explicit" is not allowed int explicit; ^"src.C", line 4: error: declaration does not declare anything int explicit; ^
"src.C", line 4: error: "explicit" is not allowed int explicit; ^ detected during instantiation of class "A<char>" at line 18
"src.C", line 4: error: declaration does not declare anything int explicit; ^ detected during instantiation of class "A<char>" at line 18
"src.C", line 18: error: specializing function "A<char>::g" requires "template<> " syntax char A<char>::g() { return 'a'; } ^
"src.C", line 4: error: "explicit" is not allowed int explicit; ^ detected during instantiation of class "A<int>" at line 21
"src.C", line 4: error: declaration does not declare anything int explicit; ^ detected during instantiation of class "A<int>" at line 21
"src.C", line 14: error: identifier "i" is undefined for (i = 0; i < 10; i++) ^ detected during instantiation of "void A<int>::f()"
This volume of errors might causing the porting engineer's heart to sink. But the source can quickly be compiled under the UDK C++ compiler by using the -Xo option described previously:
udk-machine: CC -Xo src.C udk-machine:so that it doesn't become a blocking factor in the port.
More importantly, most ANSI/ISO source language incompatibilities are not that complicated and can be straightforwardly resolved. This means that it's generally best to just change the source and get the code up to date. For instance, in this case it's simply a matter of avoiding the new keyword, using the new template specialization syntax, and adjusting to the new for loop variable scope rule. Here is the new version with three simple edits:
src2.C:
template <class T> class A { int m, n; int is_explicit; // changed public: void f(); T g(); };template <class T> void A<T>::f() { for (int i = 0; i < 10; i++) n += i; for (int i = 0; i < 10; i++) // changed m += i; }
template<> char A<char>::g() { return 'a'; } // changed
int main() { A<int> a; a.f(); }
The above compiles cleanly on the UDK C++ compiler without using any compatibility option:
udk-machine: CC src2.C udk-machine: