Automated source translation of C++ to D

[Daniel Murphy via Digitalmars-d]

"Xavier Bigand"  wrote in message news:lu81p2$2a54$1 at digitalmars.com...

> As many told it including Walter it seems impossible to be able to convert 
> arbitrary C++ code to D, but having a tool that is well documented on what 
> it can convert without issue will certainly be
> enough interesting.
>
> My point is, if some part of your C++ can't be converted you certainly can 
> refactor it to fit in something supported by the conversion tool.
> Here the point is the tool must not be able to do imperfect conversion, it 
> better to exit in error when something isn't well supported.
>
> As Andrei told, there is certainly ways to do a configurable tool, to help 
> it to convert some parts.

The main problem is that what exactly is supported depends on the 
conventions of the project being targeted.  While you can certainly refactor 
your code to fit in the style the converter expects, it's quite likely 
easier to patch the converter to understand the existing style better. 
(assuming the project is internally consistent)

eg In the dmd frontend, there were several places that #define was used to 
alias static members.  eg Type::tint expanded to something like 
Type::tarray[Tint].  I removed all of these from the source to allow 
conversion, since D's alias can't alias an expression.

In a codebase where this type of thing was significantly more common, it 
would make more sense to have the converter detect this pattern and 
automatically generate wrapper functions or something.

Unfortunately every C++ seems to be written in a different, incompatible 
subset.  Project-custom converters are able to handle these subsets 
optimally.

Luckily these tools are very simple to write and adapt, in my experience.

> Even if a such tool can't convert any C++ code, it might help to interface 
> C++ with D, by converting the main part (every day modified code) of a C++ 
> software. In this sense I am more interested by converting the C++ I write 
> than those of third party libraries. Maybe just as Facebook?

If it can't convert the whole project, then you are going to have to do some 
parts manually or leave some parts in C++.  Neither are particularly 
attractive.  Most of the debugging work I've done with DDMD was caused by 
one of those, either bugs introduced during manual conversion, or nasty 
wrong-code or alignment bugs when calling across the language boundary.

> The other question is what will be the result of the generated binary in
> term of performances?

This is completely up to you.  It is quite straightforward to have the 
generated D code exactly match the C++ code, call for call.  Or, when you 
don't care so much, C++'s new can be replaced with D's GC new.

This is true for DDMD at least.  Other projects that rely more heavily on 
C++'s struct semantics may not behave the same, it's hard to say without 
trying it.