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:

 

Manipulations with class-reference types
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 in Delphi and C# almost are identically. Delphi2C# doesn't translate these parts.but only copies them
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.
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 event handling

 

 

 

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