> > Since Digital Mars already have a C/C++ compiler it might be possible
> > to modify it so that it would be able to produce D file. I think that
> > Borland
> > uses Delphi compiler to convert Delphi files to C++ one that are used by
> > C++ Builder...
>
> Well, C++ Builder can compile Delphi sources, because it has an embedded Delphi compiler. Delphi compiled object files seem to contain interface information in a convenient binary form, so further parsing is not requiered. ;)
>

The point was that with C++ Builder, the .hpp file will get generated
automatically when compiler from C++ Builder. I don't exactly how it
works but I think that essentially the Delphi compiler is called with an
option for that... and I was wondering if this might be possible to
do something similar using Difital Mars C++ compiler...

I think the main problem is that C++ is so complex compared to most other language that it would be more difficult to start from C/C++ files.

But if we look at Borland, they start with rudimentary support and add more from version to version...


> > Another possibility might be to make the D compiler able to import .h file and make it visible some part of it... We can start by importing POD style struct, function declaration that are compatible (uses compatible parameters, return type and calling convention) and constants (define and real constant).
>
> Just look at it: all you are suggesting is to put more work on Walter. Shame on you! Digitalmars is definately not Borland or something. He doesn't even come to implement some really vital parts of D specification. ;)
>

Well... these are suggestions on how I think it might be done... I understand that often we don't have the ressource to do everything we would like. OTOH, if it is easy to uses D in a mixed language environment, it might help it a lot to become a popular language.

If I am the only one that would like it, then it might be ignored
but I do think that even just for implementing the D compiler
C stuff will be need and it might be a good investisment...

Maybe the solution would be that D be able to compile for the .NET environment and being able to uses .NET component.

> > If we do that, we could uses a special define that the D compiler would define so that we might modify the source header if required. We could also have the D version available as a define...
>
> Martin Pederson was very kind to donate a pre-processor, which would be
> a vital part of the converter, which i intend to work almost like SWIG,
> which allows exactky that. There are 2 reasons why SWIG shouldn't be used:
>
>   - it is designed to deal with languages almost imcompatible with C,
> and thus supports very few types;
>   - it is GPLed, which is bad for us. We want MIT-style license and/or a
> donation to DigitalMars.
>

Well, I think the solution would be instead to modify Digital Mars C++
compiler and/or other tools to be able to output D module...
But maybe the compiler code is too complicate for that to be
easy enough to make sense...

> > And it might also be interesting to be able to do the conversion in the opposite direction in some cases... so that D code could be used from C/C++.
>
> Can't really imagine - there are next to no libraries for D. :) Besides, it's much harder this way. First, C++ interoperation should work...
>

Well this is true if we want full support... but we might start with partial support. This might include exporting functions, POD types, alias and interfaces (for functions and interfaces, all parameters and the return value also need to be compatible).

I have read that D interfaces are COM compatible so it would also make sense to have the D compiler generate information (IDL) or being able to import an IDL...

In fact, if we are able to uses an IDL (which is probably simpler that
C and surely simpler than C++), one would be able to do an IDL
that will be usable from both C/C++ and D...

Philippe Mori wrote:
> The point was that with C++ Builder, the .hpp file will get generated
> automatically when compiler from C++ Builder. I don't exactly how it
> works but I think that essentially the Delphi compiler is called with an
> option for that... and I was wondering if this might be possible to
> do something similar using Difital Mars C++ compiler...

DMC++ is closed source -- and that for a good and understandable reason. Pumping it up is bad for community, and for D programming language...

> I think the main problem is that C++ is so complex compared to
> most other language that it would be more difficult to start from
> C/C++ files.

True.

> But if we look at Borland, they start with rudimentary support
> and add more from version to version...

That's also our way.

> OTOH, if it is easy to uses D in a mixed language
> environment, it might help it a lot to become a popular language.

Certainly.

> If I am the only one that would like it, then it might be ignored
> but I do think that even just for implementing the D compiler
> C stuff will be need and it might be a good investisment...

For implementing D compiler, current library is almost enough.

> Maybe the solution would be that D be able to compile for the .NET
> environment and being able to uses .NET component.

Yes, that would be a good and feasible thing. Someone would just have to hack the D frontend - and it's not gonna be myself since i *really* have other things to do. I'm even in the process of loosing my interest in D.

> Well, I think the solution would be instead to modify Digital Mars C++
> compiler and/or other tools to be able to output D module...
> But maybe the compiler code is too complicate for that to be
> easy enough to make sense...

We *don't* *have* DMC++ compiler code. Nor do we want it, since that's what Walter earns his living from. There are open-source compilers, but only TenDRA doesn't have licensing issues. BTW, good that you remind me of it, it's frontend is worth taking a look. :)

Ah, another idea: it is probably easy to make a D compiler that outputs TDF - a bytecode format with which tools associated with TenDRA project work.

> Well this is true if we want full support... but we might start with
> partial support. This might include exporting functions, POD types,
> alias and interfaces (for functions and interfaces, all parameters
> and the return value also need to be compatible).

The difference is, for rudimentary support importing C, only declarations need to be generated. For C++ import and for D->C/C++ export alike, big sets of wrappers have to be generated - which is simply a different kind of complexity.

> I have read that D interfaces are COM compatible so it would also
> make sense to have the D compiler generate information (IDL) or
> being able to import an IDL...

This should be a task of a separate tool... A very worthy one.

> In fact, if we are able to uses an IDL (which is probably simpler that
> C and surely simpler than C++), one would be able to do an IDL
> that will be usable from both C/C++ and D...

That's the way that SWIG has gone, and our tool should be similar...

-eye