"Joakim"  wrote in message news:ynfwlptfuzfutksbnslc@forum.dlang.org...

> Yes, I'm aware of ddmd.  You've mentioned many times that it only works because dmd is written using a very unC++-like style, to the point where github's source analyzer claims that dmd is written in 66.7% C, 28.4% D (presumably the tests right now), 4.4% C++, and 0.5% other. :)

The style dmd is written in makes it a lot easier, but it would still be possible with other styles.  As others have said the github numbers have nothing to do with the style of the code, only the naming of the files.

> Given tools like libclang, how hard do you think it'd be to translate most of actual C++ to D?  If writing such a tool would mean that C++->D translation is the path of least effort for D users who want to integrate with C++, maybe that's the approach that should be taken instead.

A tool that can translate an arbitrary C++ program to D is not going to happen.

A tool that can translate a specific C++ program to D is not particularly difficult to produce, as I've done with dmd.  eg multiple inheritance cannot be generally mapped to D code.  But in many applications, the use of multiple inheritance _can_ be mapped because it corresponds to classes + interfaces.  This type of application-specific knowledge can significantly reduce the complexity.

DDMD actually has a major additional complication that most translations would not have - it is only a partial translation (glue layer stays in C++) and therefore needs abi stability across the boundary.  I initially did a non-abi-stable translation of only the frontend, and it was rather easy in comparison.

So no, you can't magically upgrade a project from C++ to D.  But it can be done, and is not prohibitively difficult someone experienced with C++ and D. 

On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote:
> So no, you can't magically upgrade a project from C++ to D.

Hence the name "magicport"?

Sorry, could not resist.
David

"David Nadlinger"  wrote in message news:jumhdppapovcvfnwnxxq@forum.dlang.org...

> On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote:
> > So no, you can't magically upgrade a project from C++ to D.
>
> Hence the name "magicport"?
>
> Sorry, could not resist.
> David

It's only the illusion of magic. 

On Fri, 22 Aug 2014 08:29:52 +0000
David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Hence the name "magicport"?
magic is not easy, contrary to widespread beliefs. ;-)

On 8/22/14 1:29 AM, David Nadlinger wrote:
> On Friday, 22 August 2014 at 07:48:30 UTC, Daniel Murphy wrote:
>> So no, you can't magically upgrade a project from C++ to D.
>
> Hence the name "magicport"?
>
> Sorry, could not resist.
> David

It's pronounced "sufficiently advanced technology port" :)

Le 22/08/2014 09:48, Daniel Murphy a écrit :
> "Joakim"  wrote in message news:ynfwlptfuzfutksbnslc@forum.dlang.org...
>
>> Yes, I'm aware of ddmd.  You've mentioned many times that it only
>> works because dmd is written using a very unC++-like style, to the
>> point where github's source analyzer claims that dmd is written in
>> 66.7% C, 28.4% D (presumably the tests right now), 4.4% C++, and 0.5%
>> other. :)
>
> The style dmd is written in makes it a lot easier, but it would still be
> possible with other styles.  As others have said the github numbers have
> nothing to do with the style of the code, only the naming of the files.
>
>> Given tools like libclang, how hard do you think it'd be to translate
>> most of actual C++ to D?  If writing such a tool would mean that
>> C++->D translation is the path of least effort for D users who want to
>> integrate with C++, maybe that's the approach that should be taken
>> instead.
>
> A tool that can translate an arbitrary C++ program to D is not going to
> happen.
>
> A tool that can translate a specific C++ program to D is not
> particularly difficult to produce, as I've done with dmd.  eg multiple
> inheritance cannot be generally mapped to D code.  But in many
> applications, the use of multiple inheritance _can_ be mapped because it
> corresponds to classes + interfaces.  This type of application-specific
> knowledge can significantly reduce the complexity.
>
> DDMD actually has a major additional complication that most translations
> would not have - it is only a partial translation (glue layer stays in
> C++) and therefore needs abi stability across the boundary.  I initially
> did a non-abi-stable translation of only the frontend, and it was rather
> easy in comparison.
>
> So no, you can't magically upgrade a project from C++ to D.  But it can
> be done, and is not prohibitively difficult someone experienced with C++
> and D.

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.

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?

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

"Xavier Bigand"  wrote in message news:lu81p2$2a54$1@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. 

Am Thu, 21 Aug 2014 17:57:11 +0000
schrieb "Joakim" <dlang@joakim.airpost.net>:

> On Thursday, 21 August 2014 at 10:00:43 UTC, Daniel Murphy wrote:
> >
> > You might want to look at DDMD, which is automatically converted.
> 
> Yes, I'm aware of ddmd.  You've mentioned many times that it only works because dmd is written using a very unC++-like style, to the point where github's source analyzer claims that dmd is written in 66.7% C, 28.4% D (presumably the tests right now), 4.4% C++, and 0.5% other. :)

OT: That's because the "analyzer" analyzes the file name part after the last "." and dmd uses an atypical extension for C++.

-- 
Marco

On 8/21/14, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> The trouble is, D is not a perfect superset of C++, not even close

I don't think that's important for porting. To quote:

-----
Engineering teams at Mozilla and Epic ported the award-winning Unreal Engine 3 (UE3) to the Web in just four days using the powerful combination of asm.js and Emscripten, which enables developers to compile C++ code into JavaScript.[1]
-----

[1] : https://www.unrealengine.com/news/epic-games-releases-epic-citadel-on-the-web

I'm still amazed that this is even possible. But it makes me think what does JS have over D that makes this possible? I have a feeling it's only down to the number and capability of people working on such a project which guarantees it's success (JS is important, and the Unreal Engine is important).

On Sat, 6 Sep 2014 20:42:32 +0200
Andrej Mitrovic via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

there is two kinds of "porting".

first is just generation of code that will be compiled by the target compiler. this code can be messy, unreadable and unmaintainable, nobody cares until it compiles.

second is "real porting", when code is still human-readable and easy to support, just written in another language.

it's not that hard, for example, to wrtite C++ -> D translator that produces working mess. let C++ compiler to instantiate all necessary templates and so on, then use D as "high-level assembler". resulting blob will be unmaintainable, but working. but this has no sense, 'cause without original C++ code resulting D code cannot be supported by any sane human person.

UE "porting" is of second kind.