D and C APIs

[Atila Neves via Digitalmars-d]

On Tuesday, 12 January 2016 at 18:59:01 UTC, Walter Bright wrote:
> Many times I've considered simply incorporating a C compiler 
> into the D compiler, and then:
>
>   import "stdio.h";
>
> The perennial problem, however, is the C preprocessor and all 
> the bizarre things people do with it in even the most mundane 
> header files. The problem is NOT, however, implementing the 
> preprocessor, as that's already done. The problem is C #include 
> files do not exist in a vacuum; they derive their meaning based 
> on the compiler used, the predefined macros, and the host file 
> they were #include'd in.
>
> Well, and the inevitable C language extensions, different for 
> every compiler, and the developers determined to use every last 
> one of them :-(
>
> Then there's what type does 'char' map to?
>
> When the D compiler guesses wrong about all these issues, 
> there's no way to see or correct what it did, and so we wind up 
> with endless "bugs" and support issues.
>
> It's better to have a separate translator, and the user can 
> tweak the results of it.

I understand the issues. But the reality remains that since any 
C++ compiler is also a C compiler, the same one will get used to 
parse the headers and the C++ code that includes it. The result 
being that 99.9% of the time I can write C++ code that #includes 
the C headers and not have to think about it (the other 0.1% are 
the parts of C that are incompatible with C++ - people think this 
is 0 but it isn't).

It's the _only_ reason I'd personally choose to call C from C++ 
instead of D. And, unfortunately, a decision I made weeks ago. 
This discussion has made me want to try DStep again on the weird 
headers that I have and file bugs if it doesn't work.

Atila