www.digitalmars.com         C & C++   DMDScript  

D - Guide to converting C .h files to D modules

reply "Walter" <walter digitalmars.com> writes:
I wrote this in response to many questions about it:

www.digitalmars.com/d/htomodule.html
Sep 04 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
"Walter" <walter digitalmars.com> a écrit dans le message de
news:bj9bd0$4ir$1 digitaldaemon.com...
 I wrote this in response to many questions about it:

 www.digitalmars.com/d/htomodule.html

I think it would be very usefull if someone can write a tool that will automatically do the translation and that is able to convert most standard C header and most Windows headers without problems and also header files generated by MIDL from an IDL file. Even if const as a type modifier is not added to D (I think we should), I think we should support its presence for automatic import without being less safe. So we should at least support const for extern function where const is supported. We should either support fastcall for extern or automatically generate shim...
Sep 05 2003
next sibling parent reply Mark T <Mark_member pathlink.com> writes:
I think it would be very usefull if someone can write a tool that will
automatically do the translation and
that is able to convert most standard C header and most Windows headers

how about yourself?
Sep 05 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
"Mark T" <Mark_member pathlink.com> a écrit dans le message de
news:bja5hm$19b7$1 digitaldaemon.com...
I think it would be very usefull if someone can write a tool that will
automatically do the translation and
that is able to convert most standard C header and most Windows headers

how about yourself?

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... 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). 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... Thus one would be able to force something to be ignored by the D compiler if for some reason it does not works (and not properly skipped) or would be able to add some extra definition like shims for the D compiler... and even include a file where someone could put D stuff for things that where not converted. I don't have much time to do it... but I think it would be worthwhile to have it done so that typical C header files could be used... 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++.
Sep 05 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Philippe Mori wrote:
 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. ;)
 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. ;)
 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.
 Thus one would be able to force something to be ignored by the
 D compiler if for some reason it does not works (and not properly
 skipped) or would be able to add some extra definition like shims
 for the D compiler... and even include a file where someone could
 put D stuff for things that where not converted.

Yup, generating wrappers in C might come later. This is only requiered for interfacing C++.
 I don't have much time to do it...

Neither do i... Nor does anyone...
 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... -eye
Sep 05 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 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...
Sep 06 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
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
Sep 06 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Philippe Mori wrote:
 I think it would be very usefull if someone can write a tool that
 will automatically do the translation and that is able to convert
 most standard C header and most Windows headers without problems and
 also header files generated by MIDL from an IDL file.

I was actually the one who has promised to write one, but i haven't had enough time. I didn't even start the project, because i announced i'm no way willing to do it on my own, but noone wanted to join. This leads to conclusion that noone actually needs the tool.
 We should either support fastcall for extern or automatically
 generate shim...

No, not necessarily. You cannot even expect multiple C++ compilers to interoperate on __fastcall, since it's not standard. BCC and MSVC implement fastcall differently, DMC doesn't implement one at all. In general: never use fastcall for any interfaces. And if it's used in a library, i'd simply make a #define trick to convert it into Pascal convention to be able to use such a library with DMC. What would be more important, is support for C++ classes. Maybe through interfaces? There are also differencies between compilers, so SWIG simply wraps up a C++ class in a set of C functions... Maybe it's the way to go. Another thing that SWIG has done right is a selective pre-processor. Mike Wynn has also put up some ideas for the convertor. http://www.l8night.co.uk/mwynn/d/deimos.html 3-way diffing probably makes little sense. I proposed configuration files, which would discard some identifiers, and point out how to convert others. If the scanner finds new identifiers which it isn't sure how to convert, it is to add them in some section for "undecided" ones. And the user would cut-and-paste it to the other section, which describes what to do. Also, since we would have our own pre-processor, we can provide all kinds of syntax inside the header-file inside "#ifdef DEIMOS" or something alike. -eye
Sep 05 2003
parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
Hi,

"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bjaioc$1su1$1 digitaldaemon.com...
 describes what to do. Also, since we would have our own pre-processor,
 we can provide all kinds of syntax inside the header-file inside "#ifdef
 DEIMOS" or something alike.

If it would help, I would be happy to supply a preprocessor. I wrote a C99 compliant (I hope) preprocessor for another toy project of mine. Regards, Martin M. Pedersen
Sep 05 2003
next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
Martin M. Pedersen wrote:
 If it would help, I would be happy to supply a preprocessor. I wrote a C99
 compliant (I hope) preprocessor for another toy project of mine.

Ah, thanks, it probably would help. :) Is it written in C, C++ or D? And did you use any parsing framework? The only problem is, whenever it finds a macro definition, it must supply its full text to a function. This function would return a boolean result, which would tell the preprocessor, whether the definition has to be discarded or used. Another thing we need is some parser generator with D output... There is a ton which can be adapted. I would personally like something in the sort of boost.spirit ;) -eye PS. I reposted this message, this time my e-mail adress is correct. :) I just noticed the one that was entered here before has already been disabled for 15 months. :))))))))))))
Sep 05 2003
prev sibling parent reply "Martin M. Pedersen" <martin moeller-pedersen.dk> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bjas5p$29v2$1 digitaldaemon.com...
 If it would help, I would be happy to supply a preprocessor. I wrote a


 compliant (I hope) preprocessor for another toy project of mine.

Ah, thanks, it probably would help. :) Is it written in C, C++ or D? And did you use any parsing framework?

It is in plain C, and I did not use any framework. It is attached. It is a library which interface is defined by "cpp.h". "main.c" implements a traditional "cpp" command using that library, and demonstrates its use. Documentation has been a non-issue for me (until now perhaps), but the idea is that the client keeps calling cpp_gettoken() until end-of-input. A token returned is valid until the next call to cpp_gettoken(). Errors and pragmas are returned as tokens in the token stream where they appeared. It is left over to the client to do whatever it find suitable with the token. Normal preprocessing will handle errors and pragma specially, and emit the whitespaces which is also returned as tokens. If used as a frontend for a C parser, whitespaces is to be ignored, and there will also be needed some special handling of identifiers - keywords would probably need to be identified and given special token tags. Preprocessing numbers would also need to be transformed into integers or floating point literals.
 The only problem is, whenever it finds a macro definition, it must
 supply its full text to a function. This function would return a boolean
 result, which would tell the preprocessor, whether the definition has to
 be discarded or used.

The library builds a table of macros while preprocessing. This table is available, and the "cpp" command dumps it if given the "-m" option. This table could be used for other purposes, of cause. Regards, Martin M. Pedersen
Sep 05 2003
parent Ilya Minkov <minkov cs.tum.edu> writes:
Martin M. Pedersen wrote:
 It is in plain C, and I did not use any framework. It is attached.

Thanks a lot! Documentation is probably not requiered - the source is well commented. It contains a lot of C-specific stuff though. I think i convert it to D, then most source is cleaned out... -eye
Sep 05 2003