Mixed VisualD/C++ project

[Rainer Schuetze]

On 06/07/2018 17:23, Mr.Bingo wrote:
> Seems to be a bit weak. I just get a D hello world without any cross 
> compilation. For the project, it would be better to have it setup to 
> work properly using C++ as the master, since the other D projects 
> provide the D side.
> 
> I was going to play around with using C++ and D together to see if I 
> could get the best of both worlds but the test project only provides a 
> bare bones D file. I created a cpp file and added it but I Get the error 
> about stdafx. Seems like the project is not really setup properly to 
> demonstrate using C++ and D together.
> 
> It would be better to have a small "hello world" mixed language demo.

Good idea. I'll try adding an option to the project wizard that adds a 
C++ source file containing main.

> 
> In fact, what I'd like to ultimately do is provide a QT gui using C++ 
> but a D business end.
> 
> The C++ file is programmed to use pre-compiled headers. Setting it to 
> 'create' still has issues since none of the pch plumbing is taken care of.
> 
> I turned off precompiled headers and modified the code:
> 
> #include <cstdio>
> 
> void main()
> {
> 
>      printf("hello world");
>      getchar();
> }
> 
> 
> which gets the c++ called(renaming the D main to something else).
> 
> 
> by externing and such I can call the D function after initializing the 
> runtime.
> 
> 
> 
> This is the basic code I have now:
> 
> 
> module WindowsApp2;
> 
> import std.stdio;
> extern(C) int rt_init();
> extern(C) int rt_term();
> 
> extern(C++) void test()
> {
>      rt_init();
>      writeln("Hello D World!\n");
>      getchar();
> 
>      rt_term();
> }
> 
> 
> and
> 
> 
> #include <cstdio>
> 
> 
> void test();
> 
> void main()
> {
> 
>      printf("hello world");
>      test();
>      getchar();
> }
> 
> 
> 
> 
> This is what I'd like to see:
> 
> A C++/D mixed project with either the C++ or D as "master"(I believe 
> this is just which one defines main) with proper initialization and 
> pre-compiled headers. The above is a crude approximation of trying to do 
> all that, but I'd expect it to be properly done.
> 
> The idea would be to provide the proper foundation of doing C++ and D 
> mixed projects where very little trouble occurs and one can get the full 
> benefit of each language and they interact well.

I'd expect rt_init/rt_exit to be called from C++ main, so you can don't 
need special D functions to be callable.


> 
> One of the key issues I think will occur, but not sure since I haven't 
> done much C++ and D mixed, is cross referencing symbols and a lot of 
> duplicate code must be created so the C++ side can see in to D and vice 
> versa.
> 
> Maybe a tool can be automated that will take the D exports and 
> automatically bring them in to C++ in a nice and easy way rather than 
> duplicating code.
> 
> Maybe you could get some help of some people that do mixed C++ and D 
> code to provide an optimal solution that works well? It would be cool if 
> one could use C++ and D easily so that little work has to be done. This 
> would alleviate many issues that D faces dealing with lack of proper 
> libraries that are in C++. (while bindings exist they they generally rot 
> over time and don't have all the flexibility that the main version has).
> 
> 
> Also, it might be ideal to focus on such a mixed project and have the 
> ability to simply set D as the "main" host. In such cases the project 
> would reduce to a basic D project with the capabilities of adding C++ 
> code. Even if C++ is master, which would require a c++ compiler, it can 
> act just as a wrapper. (If Visual D can detect that no C++ file is used 
> then it can ignore it)
> 
> 
> The biggest thing that worries me is having to do all the plumbing 
> between the two, which seems like it could be problematic for large 
> projects... and it seems like a lot of this stuff could be automated.
> 
> e.g.,
> 
>     module testmod;
> 
>     extern(C++) test();
> 
> exports, from D, test.  In C++ we have to include test:
> 
>     void test();
> 
> this is not too much work, although it creates a dependency(if test is 
> renamed then we have to rename all locations).
> 
> A few ways to solve this is to have visual D generate a list of all 
> extern(C++) exports(or even use attributes to select them specifically) 
> and then be able to import them in to C++
> 
>     #include "D_CppExports.h"
> 
> and D_CppExports.h is automatically created and includes void test();
> 
> This is not the best solution though as it would contain all the 
> functions, might base it off the names of the modules:
> 
>     #include "D_CppExports_testmod.h"
> 
> 
> Which, since it is automatically generated reduces the dependency issues 
> significantly. (only if the module name changes will the break occur, 
> which is an easy manual fix)
> 
> There might be better ways of doing this stuff, Some interlanguage 
> libraries might be useful, for example, using a D template in C++ 
> somehow and vice versa. (not sure if it is entirely possible but it 
> would work in some cases)
> 
> With such a project that can act both as a C++ host and a D host there 
> is really no need for the other project type. Allow for GDC in the 
> project too.

I haven't seen a recent GDC for Windows, and it has never outputting 
object files that integrate with VC and the MS linker.

> Just throwing out ideas... I'm hoping getting in to the mixed side of 
> things will open a lot of doors but I'm a bit weary it might be a lot 
> more trouble than it's worth:
> 
> For example, https://dlang.org/spec/cpp_interface.html
> 
> using a D class E in C++ requires code duplication:
> 
> class E
> {
>    public:
>      virtual int bar(int i, int j, int k);
> };
> 
> 
> it would be nice if Visual D could generate the C++ mapping 
> automatically and then make it easy to import similar to the example 
> above that imports a function.
> 
> 
> Doing stuff like this reduces dependencies between the C++ and D side so 
> that when one changes something on the D side they don't have to always 
> go back and change it on the C++ side(which, at some point will become 
> overwhelming). Instead, a simple utility handles all these dependencies 
> in some way.

While easier interop without duplication between D and C++ is desirable, 
it's not a simple task. I expect that most often the C++ side is 
available, and the D side needs to be generated. There are several 
projects trying to do this, but none is perfect so far:

https://code.dlang.org/packages/dpp/~master
https://github.com/jacob-carlborg/dstep
https://github.com/Syniurge/Calypso

Visual D has it's own tool, but it is very much targeted at converting 
the Windows SDK and Visual Studio SDK.