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
