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.
