July 06, 2018
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.

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.

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.

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.




Thanks.
July 12, 2018

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.