Chad J wrote:
> That said, the two known D compilers are also C compilers (or at least
> share backends with C compilers).  What a handy coincidence.  I'd say
> that being able to link against C code shouldn't be part of the D
> spec, at least not permanently, but being able to link against C code
> should be supported by current D compilers just to get things moving for
> D.  Then maybe someday compiler writers will save some effort by
> ditching C support because no one will use C anymore.

D can link against C code right now, it just will not compile C code.

Derek Parnell wrote:
> But all joking aside, it just occurred to me that Digitalmars already has a
> tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm
> wondering if Walter could provide a new utility that can help us automate
> translation of C/C++ headers into D source code?

There's no way to do that with C++ - just take a look at any Boost headers :-). It is possible to do a 90% automatic translation of C headers.

On Sun, 14 May 2006 23:22:56 -0700, Walter Bright wrote:

> Derek Parnell wrote:
>> But all joking aside, it just occurred to me that Digitalmars already has a tool that accesses C/C++ headers ... the DigitalMars C++ compiler! So I'm wondering if Walter could provide a new utility that can help us automate translation of C/C++ headers into D source code?
> 
> There's no way to do that with C++ - just take a look at any Boost headers :-). It is possible to do a 90% automatic translation of C headers.

May I repeat a portion of my post please ...

    "a new utility that can **help** us automate
     translation of C/C++ headers into D source code"

I know that 100% automated translation is not practical. However, as DigitalMars already has a C/C++ parser that works, I was thinking that a tool based on that parser to created a best-effort translation and highlighted that which needs human effort might be a useful addition to the D tool set. Whatever you have now as a C/C++ parser has got to be better than writing a new one from scratch. I'm not asking for the source code for that parser, just a tool that would output something that could be tweaked into D code by either (or both) another tool or person.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocracy!"
15/05/2006 4:47:55 PM

Kyle Furlong wrote:

> First of all Ben:
> 
> Welcome to the D community!
> 
> I would like to apologize for the less than optimal welcome you have received so far; they should know better.

Well, most people _do_ have a sore spot for ignorant rants masked as "gentle critique"s (although I hope the post wasn't meant as an ignorant rant).

Ben, I think you're off the spot on most of your observations, and if you really care about D, you should also have taken the time to ask a few questions, not just assume that everything is the way it looks. When that is said, some of your observations are correct, and D need more contributors, so why not help D along. Most people on this newsgroup tend to respond positively to positive and constructive suggestions, and contributions.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Chad J wrote:

>>True.  This has been discussed before, but has been rejected
>>intentionally.  We don't want every D compiler to end up being a C
>>compiler, too.
> 
> This has always been a sore spot with me and D.  There is A LOT of C/C
> code out there to leverage off of, and to me it is beyond inconvenient
> to require translation of all of those headers.  Also, rewriting all of
> the code with a handful of D developer seems like insanity to me.

If you use a tool to help you, translating C headers is not THAT bad.
Translating C++ headers is trickier, but can be done too if needed...
I think that D has it slightly easier than some other languages, since it only needs to provide an import module - not any wrapper stubs, etc.

It's one of the clear language decisions of D to break the source level compatibility with C, and C++, and even with older versions of D itself.
If you need C compatibility, then C++ is a better choice. If you need C++ compatibility, then even Objective-C could be the better choice.

But it is still easier to link to C code in D, than what it is wih Java.
You don't need to write or generate the JNI (or CNI) stubs, and so on...

> That said, the two known D compilers are also C compilers (or at least
> share backends with C compilers).  What a handy coincidence.  I'd say
> that being able to link against C code shouldn't be part of the D
> spec, at least not permanently, but being able to link against C code
> should be supported by current D compilers just to get things moving for
> D.  Then maybe someday compiler writers will save some effort by
> ditching C support because no one will use C anymore.

AFAIK, the support for linking against C libraries is a huge part of D.
For instance, the Phobos std D library uses a lot of the std C library ?
Not being able to link with "C" means *no* external functions at all...
(those externals can be written in anything, if they export a "C" API)

And for a language that supports inline assembler, it would be a bit strange to drop support for linking to "portable assembler" (aka. C) ?

> [...]
> Oh and whatever happened to all of those C header to D translation
> projects?  Did people run into some sort of fundamental law of the
> universe that made it impossible, or was it just difficult enough to
> discourage everyone for a couple years?

Most of us translated the headers we needed, and got on with coding...
Like someone said, 100% for all cases is hard - but it does like 90% ?
There are several tools available, depending on what type that you like.

It's a "known bug" with DMD, that such a tool isn't bundled by default.
I did a perl hack that has worked OK (for me) for translating several large library headers from C to D, maybe I should bundle it with GDC ?

--anders

Derek Parnell wrote:
> May I repeat a portion of my post please ...
> 
>     "a new utility that can **help** us automate
>      translation of C/C++ headers into D source code"
> 
> I know that 100% automated translation is not practical. However, as
> DigitalMars already has a C/C++ parser that works, I was thinking that a
> tool based on that parser to created a best-effort translation and
> highlighted that which needs human effort might be a useful addition to the
> D tool set. Whatever you have now as a C/C++ parser has got to be better
> than writing a new one from scratch. I'm not asking for the source code for
> that parser, just a tool that would output something that could be tweaked
> into D code by either (or both) another tool or person.

One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image.

The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.

Walter Bright wrote:

> One of my concerns about me writing such a tool is that people will have too high expectations of it, and when it fails to deliver 100% automated conversion, it'll give the rest of D a bad image.

Adding it as a part of the compiler might be tricky to do "right"...

People will still need such a tool, though ? As 90% is more than "0%".
But I can see the problems with bundling as a "silver bullet" package.

> The first thing someone new to D will do is try to run the converter across all their C header files. The converter will fail miserably. They'll just dismiss D as a buggy piece of ****.

Funny, that's about what happened with Ddoc and my own D files :-)

But I didn't just dismiss Ddoc because of that, as it had potential ?
(even if I'm still using Doxygen, because it has some neat features)

--anders

Walter Bright wrote:
> D can link against C code right now, it just will not compile C code.

Sorry I didn't mean link.  Oh and I said C plus plus a lot, but I think the ng cut out the plus plus.  Basically I just want to be able to import .h  files and have it just work.

If it is actually easier to convert all of the C plus plus headers to D "headers" by hand than by creating some automated mechanism in the compiler, then OK, no full automated conversion.  I find that hard to believe though.

I am thinking game creation middleware for myself.  This would involve hand translating a whole bunch of stuff, just to try it out.  I may not even use the results for very long.  I suppose I could code in C plus plus to try stuff out, but then I'm doing C plus plus coding and not D coding, and that's just about as bad as the header conversion (for me anyways).  Then if the maintainers of a C plus plus library change the library, the D wrappers become outdated and need fixing.

I have even more trouble believing that current D compilers shouldn't support C plus plus integration just because it might make C plus plus compilation a required capability of a D compiler.

Anders F Björklund wrote:
> If you use a tool to help you, translating C headers is not THAT bad.
> Translating C++ headers is trickier, but can be done too if needed...
> I think that D has it slightly easier than some other languages, since it only needs to provide an import module - not any wrapper stubs, etc.

Is there a good tool for C plus plus to C to D translation?

> But it is still easier to link to C code in D, than what it is wih Java.
> You don't need to write or generate the JNI (or CNI) stubs, and so on...

Haha, so true.

> AFAIK, the support for linking against C libraries is a huge part of D.
> For instance, the Phobos std D library uses a lot of the std C library ?
> Not being able to link with "C" means *no* external functions at all...
> (those externals can be written in anything, if they export a "C" API)
> 
> And for a language that supports inline assembler, it would be a bit strange to drop support for linking to "portable assembler" (aka. C) ?

I think I confused the term "linking" with... I don't even know what to call it then.  C plus plus integration maybe.

> Most of us translated the headers we needed, and got on with coding...
> Like someone said, 100% for all cases is hard - but it does like 90% ?
> There are several tools available, depending on what type that you like.
> 
> It's a "known bug" with DMD, that such a tool isn't bundled by default.
> I did a perl hack that has worked OK (for me) for translating several large library headers from C to D, maybe I should bundle it with GDC ?
> 
> --anders

I'd probably be pretty happy with 90-95% C plus plus header conversion.

I'd like to see that perl hack.  Is it online somewhere?

I remember trying SWIG to get some C plus plus to D conversion going on, but that setup didn't work very well.  Required a lot of work just to use it.  Cure is worst than the disease sort of thing.

I noticed an h2d project on dsource.  But I think that only worked on linux, or something.  For some reason I wasn't able to even try it.

I don't remember seeing any tools of this kind that were written in D. Kind of unfortunate, probably makes it difficult to pool effort out of D programmers for something that isn't written in D.

Any other tools I should look at?

Chad J wrote:

> I have even more trouble believing that current D compilers shouldn't support C plus plus integration just because it might make C plus plus compilation a required capability of a D compiler.

This isn't a "just because", C++ is known to be excessively hard to compile right, and one of the goals of D is to be easy to compile, to make sure you actually get compilers that are standard compliant and produce correct code within a sensible timeframe.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi