What is not translated

Top  Previous  Next

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

 

The conversion to C++Builder code seamlessly works together with the existing adoption to the Delphi RTL/VCL, but manual justifications to some helper names might be necessary. Delphi2Cpp makes little effort to cooperate with own Delphi code. An example of using a Delphi interface is here. If you need more, please contact me.

 

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

 

Inline assembler code in Delphi and C++ almost are identically. Delphi2Cpp doesn't translate these parts.but only copies them.
Code that relies on the internal members or memory layout of Delphi types cannot be converted automatically.
Delphi2Cpp always assumes unique names.But e.g. there might be symbols from the operation system, which differ in notation..
parameters for destructors are ignored
In Delphi everything inside of a unit is accessible to each other. As s compromise only classes are made friends to each others
Manual post-processing to achieve const-correctness is necessary.
Multithreading classes and routines are formally translated, but not checked by an expert
Resource strings simply are treated as non-resource strings
In C++ classes with abstract methods cannot be created
The consequences of the ZEROBASEDSTRING directive are not corrected automatically.
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.
Advanced techniques such as ActiveX, COM, CORBA etc. are not specifically supported
For C++Builder Variant is supported for other compilers not, but TVarRec
At the current state Delphi2Cpp doesn't deal with method resolution clauses
Delphi2Cpp has no solution to simulate the results of overwritten DefineProperty functions at the conversion of dfm-files.

 

 

Special problems:

 

lifetime extension of bound variables

https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors

 

 

       

 

 

 

 

 

 

 



This page belongs to the Delphi2Cpp Documentation

Delphi2Cpp home  Content