Cpp2Java

The most ambitious project which was ever done with TextTransformer is the translation from a company software written in C++ into Java. C++ is a very complex programming language and there isn't any publicly available, useable parser till now. It wasn't aim of the project to build such a thing. The project was rather restricted to be able to parse the approx. 120000 lines of the given source code. It should be worked on an automatic conversion of the parsed code with an acceptable effort. It was the aim that a final manual post-processing should be as low as possible.
At the first glance, such a translation doesn't seem that difficult at all since the code of the two object-oriented languages often resembles each other very much. A direct reproduction of the source code, however, necessarily will fail. E.g. there aren't any overloaded operators like in C++ in Java. The assignment of a string value to another string object which calls the assignment operator in C++ automatically would simply result in copying the object reference in Java. The explicit assign method of the object would have to be called instead. An assignment of pointers would, however, be correct. Similarly the "equals" method must be called for the test of the equivalence of the values of two objects in Java, instead of the "==" operator. The type information of the respective objects has to be taken into account, when the Java code is written. It was not the intention to produce compilable Java code in doubtful cases, rather the Java compiler should be forced to produce corresponding error messages.

The main steps of the translation shall be represented now.

Substitution of the preprocessor directives

Before a translation of the C++ source files can be started, the preprocessor directives must be replaced. This should happen in a way which maintained the meaning of these directives.

You can get the C-preprocessor without this special treatments here:

http://www.texttransformer.org/c_pp_en.html

C++-Parser

The project is based on a C++ grammar for ANTLR made by David Wigg and others:

http://www.antlr.org/grammar/1132152279791/CPP_parser_v_3.1.zip

The project was imported into the TextTransformer semiautomatically and completed by hand so far, that it could parse all source files. Type definitions, variable declarations etc. were treated in a special way.

Type definitions

As soon as an identifier which stands for a type is recognized in a type definition, it is added to a corresponding placeholder token "TYPE". If the type then is used in the code again, it is recognized directly as such. E.g. with:

typedef unsigned int uint;

the new type name "uint" is introduced. Later, a declaration as:

uint ui;

will be parsed as: TYPE ID ";".
The same with the identifiers for classes, namespaces or type names in template declarations.

This method only can work, if the respective scopes in which the types etc. exists are updated synchronously with parsing the code. This update doesn't have only to be carried out in the main parser but also if new types are recognized in a look-ahead.

The C++ libraries, particularly the stl were not translated but simulated as fas as needed. I.e. in an initialization function the required declaration information was set in corresponding tables (tree structures).

Tree structure

The source code of the company software was structured generally such, that there was a single file for every class with an accompanying header. In Java there is only a file for every class. For the translation, therefore at first a tree from the class declaration of the header was built and then the function implementations of the C++ file were put into it. So the C++ files are integrated into the header.

Schematic example:

class CClass
{
public:

CClass(int i);

void setter(int i);

private:
int m_i;
};

CClass::CClass(int i)
: m_i(i) {}

void CClass::setter(int value)
{
  m_i = value;
}

=> Java

public class CClass
{
public CClass(int i) { m_i = i; };
public void  setter(int value) { m_i = value; }
private int m_i;
};

At the example can be seen that one has to take care of the names of the function parameters. I fthere are default values in the function declarations, the function is on split into a number of functions of the same name with a different number of parameters. All of them are inserted into the tree.

Generating the Java code

If the tree is created as just described, the Java output is made in the correct order when the leaves are written while the tree is processed top down. But the respective types have to be taken into account, as mentioned above. This is done in the following way:

In the TextTransformer "function tables" can be created. In such a table functions are assigned to labels. When a node with a certain label is passed, the assigned function is executed. E.g. the following function could be assigned to equivalence expressions:

m_ftPrint.add("equality_expression", Print_equalitiy_expression);

Two auxiliary functions "IsObjectType" and "IsNonObjectType" are used in "Print_equalitiy_expression" now to distinguish between the call of an "equals" function and the simple use of the operator. The properties for the determination of the object type are stored in the tree and in external tables as node attributes. The Cpp2Java project isn't completed here yet, though. The determination of resulting types isn't implemented for complex expressions yet.

The evaluation of type information has been developed much further in the program Delphi2Cpp in the meantime. Delphi2Cpp converts Delphi code to C++.