A gentle critque..

Anders F Björklund afb at algonet.se
Mon May 15 00:33:24 PDT 2006


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



More information about the Digitalmars-d mailing list