I wrote this in response to many questions about it:

www.digitalmars.com/d/htomodule.html

"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...

>
>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?

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

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

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. :))))))))))))

"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
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?

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

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

"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++.

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