What is not translated

Top Previous Next

There are some principle problems - listed below - at the conversion of Delphi code to C# which cannot be resolved by an automatic translator. But even things which Delphi2C#, normally can handle may fail in complex nested cases. Sometimes Delphi2C# generates explicit "todo"-comments where something has to be completed manually.

Some Delphi constructs, which aren't, automatically translated yet are:

•	Parts of the RTL operate directly on the virtual method table of objects. These parts aren't reproduced. The most important consequence of this lack is, that streaming of forms and other types isn't possible in Delphi manner.

•	Inline assembler code cannot be used in C#

•	virtual class methods.

•	Delphi2C# always assumes unique names.But e.g. there might be symbols from the operation system, which differ in notation.

•	Some problems with constructors remain. E.g. Delphi2C# cannot distinguish constructors with equal signatures.

•	Class helpers cannot change the fields of the helped class itself, though this is possible for records

•	Manual post-processing to achieve const-correctness is necessary.

•	The consequences of the ZEROBASEDSTRING directive are not corrected automatically

•	While typed pointers can be simulated,the compilation of code using untyped pointers often fails.

•	The keyword absolute cannot be converted adequately

•	Little effort has been done to test the COM technologies of the Delphi ActiveX framework.

•	At the current state Delphi2C# doesn't deal with message maps.

•	At the current state Delphi2C# doesn't deal with method resolution clauses

Special problems:

lifetime extension of bound variables

Most of the basic input output types and functions are converted, but not all. E.g. the writing and reading "file of record" isn't possible yet. Also the width and precision arguments in write operations aren't converted correctly yet.

This page belongs to the Delphi2C# Documentation

Delphi2C# home Content