On 2/4/2018 2:27 PM, Boris-Barboris wrote:
Ability to interface with C using C header files of a target library\executable as-is. Being able to understand the interfaces your operating system provides, described on the language it uses, is a huge criteria to pick C for your particular task.

BetterC is close enough to D that understanding the C API docs is not much of any issue.

Close-to-OS\Kernel-space\embedded seems to me as the main use case for C. It is the main C's benefit - you can interact with huge code blobs that you cannot rewrite, because you speak the same language. D does not, AFAIK, offer C header parsing.

True, D cannot directly read .h files. There are tools, though, to convert C .h files to D.

I have thought about building this into D many times, especially since the Digital Mars C compiler is now available since it is Boost licensed.

Stuff like https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html ... It all takes years to build all these tools and gimmicks. If you can't use\reuse them from D, you'd beter be off writing in C imo.

D has a pretty good chunk of those already built in. The others don't come up very often, and can be done using D's inline assembler.

Reply via email to